Re: Add a greedy join search algorithm to handle large join problems - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: Add a greedy join search algorithm to handle large join problems
Date
Msg-id CAFj8pRCO5ocbr-wFWx5QsKdfkW-=XuQ6zkW5FES7ERQZQHtpwQ@mail.gmail.com
Whole thread Raw
In response to Re: Add a greedy join search algorithm to handle large join problems  (John Naylor <johncnaylorls@gmail.com>)
Responses Re: Add a greedy join search algorithm to handle large join problems
List pgsql-hackers


čt 11. 12. 2025 v 3:53 odesílatel John Naylor <johncnaylorls@gmail.com> napsal:
On Wed, Dec 10, 2025 at 5:20 PM Tomas Vondra <tomas@vondra.me> 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.

 

--
John Naylor
Amazon Web Services


pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Consistently use palloc_object() and palloc_array()
Next
From: Amit Kapila
Date:
Subject: Re: POC: enable logical decoding when wal_level = 'replica' without a server restart