public inbox for [email protected]
help / color / mirror / Atom feedFrom: Pavel Stehule <[email protected]>
To: Tomas Vondra <[email protected]>
Cc: John Naylor <[email protected]>
Cc: Chengpeng Yan <[email protected]>
Cc: [email protected] <[email protected]>
Subject: Re: Add a greedy join search algorithm to handle large join problems
Date: Thu, 11 Dec 2025 18:33:52 +0100
Message-ID: <CAFj8pRASJuRQKHOoBTnR5aRUeRKpNAmrYQcBrQb=yqeZ_8me9Q@mail.gmail.com> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<CANWCAZY529EPHyo1kLnEzjFBq-UaDPc3KErK=ApqDZZ1Oc-XHg@mail.gmail.com>
<CAFj8pRCO5ocbr-wFWx5QsKdfkW-=XuQ6zkW5FES7ERQZQHtpwQ@mail.gmail.com>
<[email protected]>
čt 11. 12. 2025 v 18:07 odesílatel Tomas Vondra <[email protected]> napsal:
> On 12/11/25 07:12, Pavel Stehule wrote:
> >
> >
> > čt 11. 12. 2025 v 3:53 odesílatel John Naylor <[email protected]
> > <mailto:[email protected]>> napsal:
> >
> > On Wed, Dec 10, 2025 at 5:20 PM Tomas Vondra <[email protected]
> > <mailto:[email protected]>> wrote:
> > > I did however notice an interesting thing - running EXPLAIN on the
> 99
> > > queries (for 3 scales and 0/4 workers, so 6x 99) took this much
> time:
> > >
> > > master: 8s
> > > master/geqo: 20s
> > > master/goo: 5s
> >
> > > It's nice that "goo" seems to be faster than "geqo" - assuming the
> > plans
> > > are comparable or better. But it surprised me switching to geqo
> > makes it
> > > slower than master. That goes against my intuition that geqo is
> > meant to
> > > be cheaper/faster join order planning. But maybe I'm missing
> > something.
> >
> > Yeah, that was surprising. It seems that geqo has a large overhead,
> so
> > it takes a larger join problem for the asymptotic behavior to win
> over
> > exhaustive search.
> >
> >
> > If I understand correctly to design - geqo should be slower for any
> > queries with smaller complexity. The question is how many queries in the
> > tested model are really complex.
> >
>
> Depends on what you mean by "really complex". TPC-DS queries are not
> trivial, but the complexity may not be in the number of joins.
>
> Of course, setting geqo_threshold to 2 may be too aggressive. Not sure.
>
I checked the TPC-H queries and almost all queries are simple - 5 x JOIN --
2x nested subselect
>
>
> regards
>
> --
> Tomas Vondra
>
>
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: Add a greedy join search algorithm to handle large join problems
In-Reply-To: <CAFj8pRASJuRQKHOoBTnR5aRUeRKpNAmrYQcBrQb=yqeZ_8me9Q@mail.gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox