Hi,
GEQO's only function, basically, is to search for the join order to use.
> If you're constraining the join order completely with
> join_collapse_limit=1 then forcing the GEQO path to be taken would just
> add pointless overhead. (If it does anything at all ... I don't remember
> the logic exa
=?UTF-8?Q?Juan_Jos=C3=A9_Santamar=C3=ADa_Flecha?=
writes:
> In an environment with geqo_threshold=1 and join_collapse_limit=1, would
> the planner be GEQO exclusive (and syntactic)?
GEQO's only function, basically, is to search for the join order to use.
If you're constraining the join order com
Hi,
> After some testing in order to lower the planning time we ended bringing
> > down the GEQO values, and we have the best results with:
>
> > from_collapse_limit = 150
> > join_collapse_limit = 150
> > geqo_threshold = 2
> > geqo_effort= 2
>
> Hmm. The trouble with this approach is that you'r
=?UTF-8?Q?Juan_Jos=C3=A9_Santamar=C3=ADa_Flecha?=
writes:
> We recently had an issue in production. We have queries that are
> procedurally generated by an Object/Relational Mapping framework. Some of
> these queries are huge, involving over 120 tables.
Yeah, you're going to have problems with t
Hi,
We recently had an issue in production. We have queries that are
procedurally generated by an Object/Relational Mapping framework. Some of
these queries are huge, involving over 120 tables.
With the following parameters the planner seemed to be getting very bad
plans for some of these queries
