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 по дате отправления: