Tom Lane wrote:
>Mike Mascari <mascarm@mascari.com> writes:
>
>
>>Tom Lane wrote:
>>
>>
>>>Uh ... dare I ask whether you think it's too high? Or too low?
>>>
>>>
>>>
>>Too low. In fact, after testing some of my queries which are a bit large
>>(# of tables) in size, I usually just wind up turning it off.
>>
>>
>
>Well, that's why it's configurable ;-).
>
True!
>But don't you find that it
>takes a long time to plan the larger queries? How many tables are
>involved, exactly?
>
>
Well, this particular query uses a UNION where the first SELECT query is
composed of an 11-way join, and the second 5. So it is not testing the
64-way join scenario. From memory, the most joins I execute in a single
query is in the low twenties. In those scenerios, I had used explicit
join syntax to improve planning time.
I ran a crude script to test the differences in planning time (EXPLAIN)
and execution time (EXPLAIN ANALYZE). I wanted to do the ANALYZE as well
since the plans generated were different and I feared the GEQO generated
plan may be the actual cause of the sluggishness, instead of the actual
planning. The script just feeds the SQL to psql, so I know it is timing
the client, connection costs, psql formatting, etc...a.k.a. crude. But
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
Mike Mascari