From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Mike Mascari <mascarm(at)mascari(dot)com> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: I got bit by that darn GEQO setting again... |
Date: | 2004-01-17 20:57:45 |
Message-ID: | 19580.1074373065@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Mike Mascari <mascarm(at)mascari(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Leif K-Brooks | 2004-01-17 23:47:18 | Automatic joins? |
Previous Message | Mike Mascari | 2004-01-17 20:40:49 | Re: I got bit by that darn GEQO setting again... |