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<tgl@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
selena@endpoint.com
503-282-2512
