Объясните проблему с планом с помощью пункта group by в postgresql 8.4

Ниже приводится подробное объяснение, связанное с объяснением плана с проблемой группировки по пунктам.

таблица: web_categoryutfv1_24hr_ts_201209
столбцы: "5mintime", категория, хиты, байты, appid
строки: 871
Индексы: "web_categoryutfv1_24hr_ts_201209_idx" btree ("5mintime")

Я выполняю следующий запрос:

select count(*) over () as t_totalcnt,
       max(hits) over () as t_maxhits,
       max(bytes) over () as t_maxbytes,
       *
from (
  select category,
         sum(hits) as hits,
         sum(bytes) as bytes
  from (
    select "5mintime",
           category,
           hits,
           bytes,
           appid,
           0 as tmpfield
    from web_categoryutfv1_24hr_ts_201209
    where "5mintime" >= '2012-09-12 00:00:00'
    and   "5mintime" < '2012-09-19 00:00:00'
  ) as tmp
  where "5mintime" >= '2012-09-12 00:00:00'
  and   "5mintime" <= '2012-09-18 23:59:59'
  and   appid in ('')
  group by category
  order by hits desc
) as foo limit 10

Я получил общий возврат строки 55 из переменной t_totalcnt. Теперь я проанализировал web_categoryutfv1_24hr_ts_201209 таблицу и снова запустил тот же запрос с объяснением.

Получаю следующий план выполнения:

-> Limit  (cost=31.31..31.61 rows=10 width=580)
->  WindowAgg  (cost=31.31..32.03 rows=24 width=580)
->  Subquery Scan foo  (cost=31.31..31.61 ***rows=24*** width=580)
      ->  Sort  (cost=31.31..31.37 rows=24 width=31)
            Sort Key: (sum(web_categoryutfv1_24hr_ts_201209.hits))
            ->  HashAggregate  (cost=30.39..30.75 rows=24 width=31)
                  ->  Seq Scan on web_categoryutfv1_24hr_ts_201209  (cost=0.00..27.60 rows=373 width=31)
                      Filter: (("5mintime" >= '2012-09-12 00:00:00'::timestamp without time zone) AND ("5mintime" < '2012-09-19 00:00:00'::timestamp without time zone) AND ("5mintime" >= '2012-09-12 00:00:00'::timestamp without time zone) AND ("5mintime" <= '2012-09-18 23:59:59'::timestamp without time zone) AND ((appid)::text = ''::text))

Теперь я получил объяснение плана, поставив HashAggregate (cost = 30,39..30,75 rows = 24 width = 31), в котором говорится, что rows = 24, в то время как на самом деле общий возврат строки должен быть 55 Когда я удаляю предложение group by из запроса, я получил 373 строки в выводе плана объяснения, а также фактическое выполнение запроса.

Итак, я хочу знать, есть ли проблема с планом объяснения и предложением группировки в запросе?


person jenitshah    schedule 21.09.2012    source источник


Ответы (1)


Строки, показанные в плане выполнения, являются оценками. Пока они находятся где-то в пределах правильной величины, все в порядке. Если они полностью отключены, это обычно означает, что ваша статистика устарела.

Имеет смысл, что удаление group by изменяет ожидаемое количество строк, поскольку group by уменьшит их.

Так что я не вижу здесь никаких проблем.

Вы можете использовать explain analyze для сравнения фактических и реальных чисел в плане выполнения.

person a_horse_with_no_name    schedule 21.09.2012