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
