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

From lakshmi
Subject Re: Add a greedy join search algorithm to handle large join problems
Date
Msg-id CAEvyyThu3W12mwby-Ocgg=MruEUwuFDb-X=LptTGnNFsbUY3Rw@mail.gmail.com
Whole thread
In response to Re: Add a greedy join search algorithm to handle large join problems  (lakshmi <lakshmigcdac@gmail.com>)
List pgsql-hackers


On Mon, Feb 16, 2026 at 4:56 PM lakshmi <lakshmigcdac@gmail.com> wrote:

Hi Tomas,

Thank you for the clarification. You’re right that the synthetic test doesn’t strongly constrain join order and, with the default  join_collapse_limit ,  the DP comparison was limited.

I’m now preparing follow-up tests using selected JOB queries and adjusted planner settings to provide a fair and more realistic comparison. I’ll share the results soon.


         Hi Tomas,

         Following up on my previous message, I ran some additional tests using a few selected JOB queries with DP, GEQO and GOO under the same planner settings.

        Configuration used:

  • join_collapse_limit = 100
  • from_collapse_limit = 100
  • max_parallel_workers_per_gather = 0
  • PostgreSQL 19devel with the GOO v5 patch
       Here is a summary of the results: 

Query   DP Plan(ms)   DP Exec(ms)   GEQO Plan(ms)   GEQO Exec(ms)   GOO Plan(ms)   GOO Exec(ms)
-----------------------------------------------------------------------------------------------
12b     4.97          0.16          54.57           0.11            4.18           0.12
24a     88.94         0.21          67.10           0.12            6.26           0.12
26b     68.58         0.20          44.44           0.10            3.90           0.07
29a     1903.9        0.24          14.73           0.22            25.47          0.26
33c     163.25        0.28          52.93           0.18            3.98           0.07
 
     Overall, GOO consistently shows much lower planning time than DP, and is comparable to GEQO on larger join queries. Execution times are generally similar across the planners.

      Regards,
     Lakshmi 

pgsql-hackers by date:

Previous
From: shveta malik
Date:
Subject: Re: Skipping schema changes in publication
Next
From: Álvaro Herrera
Date:
Subject: Re: Reject ADD CONSTRAINT NOT NULL if name mismatches existing domain not-null constraint