Re: I got bit by that darn GEQO setting again...

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: I got bit by that darn GEQO setting again...
Дата
Msg-id 19580.1074373065@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: I got bit by that darn GEQO setting again...  (Mike Mascari <mascarm@mascari.com>)
Список pgsql-general
Mike Mascari <mascarm@mascari.com> writes:
> as you can see, over ten runs for each category, GEQO loses big. I get
> (in seconds):

>       label      | count |  avg   |       stddev
> -----------------+-------+--------+---------------------
>  NO GEQO PLAN    |    10 | 0.8809 | 0.00564604089409752
>  NO GEQO ANALYZE |    10 | 1.1534 |  0.0093594871654564
>  GEQO PLAN       |    10 | 3.0127 |   0.119783183757633
>  GEQO ANALYZE    |    10 | 6.0446 |    2.50524499578163

Interesting.  I'd expect that GEQO might sometimes not pick a good plan
(it is a quasi-random search after all, and could miss the best plan).
The large stddev for the last row shows that you don't always get the
same plan, which is expected.

But those numbers say it is actually slower in choosing a plan than the
regular planner.  This should definitely not be the case --- there's no
point at all in GEQO if it doesn't save planning time.

Can you send me the exact query being tested here, as well as the
database schema (pg_dump -s)?

            regards, tom lane

В списке pgsql-general по дате отправления:

Предыдущее
От: Mike Mascari
Дата:
Сообщение: Re: I got bit by that darn GEQO setting again...
Следующее
От: Leif K-Brooks
Дата:
Сообщение: Automatic joins?