| From: | John Naylor <johncnaylorls(at)gmail(dot)com> |
|---|---|
| To: | Tomas Vondra <tomas(at)vondra(dot)me> |
| Cc: | Chengpeng Yan <chengpeng_yan(at)outlook(dot)com>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Add a greedy join search algorithm to handle large join problems |
| Date: | 2025-12-11 02:53:09 |
| Message-ID: | CANWCAZY529EPHyo1kLnEzjFBq-UaDPc3KErK=ApqDZZ1Oc-XHg@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, Dec 10, 2025 at 5:20 PM Tomas Vondra <tomas(at)vondra(dot)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.
--
John Naylor
Amazon Web Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Ashutosh Bapat | 2025-12-11 03:06:11 | Re: POC: make mxidoff 64 bits |
| Previous Message | Peter Geoghegan | 2025-12-11 02:21:39 | Re: index prefetching |