Re: GEQO plans much slower than standard join plans

> I'm not entirely sure I follow what tests you did, some of which might
> not have been shared on the list. Also, what do you mean by "better
> plans, but also faster plans"? What's the difference?

Sorry, I should have been clearer. With "better plans" I meant faster
execution times and with "faster plans" I mean faster planning times.

> It seems to me you're implying you get faster planning with geqo=off.
> That seem counter-intuitive to me, but maybe it can happen. I however
> don't see any example demonstrating that in the results you shared (and
> I already suggested what data to look at).

Yes, I also found that counterintuitive. By turning geqo = off
(join/from_collapse_limit were 14) and looking at some metrics we obtained
from pg_stat_statements, we found that planning times of the affected
queries (the ones which would make use of GEQO) mostly increased (but not
by much), which is already the documented behavior. However, one particular
query with the same structure like the one on treejoin-14-dims.sql
(attached to the first email) had a _decrease_ on planning and execution
times, so geqo = off for this query yielded faster plans than geqo = on.
This counterintuitive behavior is the reason that I created and shared the
script that tried to reproduce it. I'm not sure whether you've run it or
not, but on every machine I have run so far I had a 10 fold increase on TPS
and a 10 fold decrease on planning times if I turn geqo = off.

I guess what I'm trying to show is that, in very particular cases, GEQO may
harm planning times, that's why I felt a little disclaimer could be useful.
I'm not sure what else I can add here.

Regards,
Carlo

On Tue, Oct 28, 2025 at 11:05 PM Tomas Vondra <tomas(at)vondra(dot)me> wrote:

> On 10/28/25 16:43, Carlo Sganzerla wrote:
> >> Another question is whether the difference is in planning or execution.
> >> I'd expect geqo=on makes planning faster and execution slower, but maybe
> >> that's not true for your test. It shouldn't be difficult to verify using
> >> pg_stat_statements (which tracks both plan and exec time).
> >
> > We started experimenting and we already see some results that point out
> > that we have not only better plans, but also faster plans. Our overall
> > plan load was already somewhat low because of extensive use of prepared
> > statements, so that in theory also reduces the load of not enabling
> > GEQO. However, we tested a bit without prepared statements and had
> > similar results as we did on the test.
> >
>
> I'm not entirely sure I follow what tests you did, some of which might
> not have been shared on the list. Also, what do you mean by "better
> plans, but also faster plans"? What's the difference?
>
> It seems to me you're implying you get faster planning with geqo=off.
> That seem counter-intuitive to me, but maybe it can happen. I however
> don't see any example demonstrating that in the results you shared (and
> I already suggested what data to look at).
>
> > I'm not sure if I'm overstepping here, but wouldn't it be worthwhile to
> > add a little disclaimer on the docs regarding such cases? I guess that
> > the hard thing about elaborating database documentation is that you have
> > to document generically enough so the information makes sense to most
> > reasonable workloads, so documenting every exception is not a good idea,
> > but on this case I feel that the docs gave too much the impression that
> > GEQO *always* improves planning performance. I was thinking of adding a
> > little "addendum". I've attached a patch for your consideration.
> >
> >> I'm not particularly familiar with the GEQO internals, so I can't point
> >> at specific issues. But I've heard from a couple experienced developers
> >> that they consider GEQO ineffective / not the right approach.
> >
> > In my view, this "addendum" also leaves some room to these other
> > considerations without compromising readability.
> >
> > I'd like to hear your thoughts on that.
> >
>
> Dunno. I'm not convinced geqo=on can increase planning time. Or maybe I
> don't understand the results you've shared.
>
>
> regards
>
> --
> Tomas Vondra
>
>