In the spirit of helping wrap-up 8.4 todo items...
Robert Haas wrote:
On Mon, May 25, 2009 at 6:15 PM, Tom Lane<t...@sss.pgh.pa.us> wrote:
Now I'm still not exactly happy with GEQO, but it's surely a lot better
than it was in the fall of 2000. So on the whole it does seem that the
current relationships between from_collapse_limit, join_collapse_limit,
and geqo_threshold are based on obsolete information and should be
revisited. I don't have any data at hand to suggest specific new
default values, though.
For 8.4, I'd be happy to just improve the documentation. I think this
sentence could just be deleted from the section on
from_collapse_limit:
It is usually wise to keep this less than<xref linkend="guc-geqo-threshold">.
We could put some other explanation in place of that sentence, but I'm
not exactly sure what that explanation would say. I guess the point
is that setting from_collapse_limit< geqo_threshold may delay GEQO
planning considerably in the face of complex subqueries, because
pulling up subqueries increases the size of the FROM list (I think).
That could be good if you want your query plans to be more
deterministic, but there's no guarantee they'll be good. Setting
from_collapse_limit> geqo_threshold is basically saying that the
standard planner will always have subqueries pulled up, so
from_collapse_limit should be based on what the pain point will be for
GEQO.
My vote would be to provide some information.
Suggested revision of Robert's prose:
Because genetic query optimization may be triggered, increasing
from_collapse_limit should be considered relative to <xref
linkend="guc-geqo-threshold">.
-selena
--
Selena Deckelmann
End Point Corporation
sel...@endpoint.com
503-282-2512
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
