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 CAEvyyTigh2eB9hGirHzAC9j3SrMW1otMNxm7yHYOU3xs8x+FLA@mail.gmail.com
Whole thread
In response to Re: Add a greedy join search algorithm to handle large join problems  (Tomas Vondra <tomas@vondra.me>)
Responses Re: Add a greedy join search algorithm to handle large join problems
List pgsql-hackers

Hi Tomas,

Thank you for the question.
The 15-table and 20-table results I shared were obtained using a synthetic join workload designed to stress join-order planning and measure planning-time scaling, rather than a JOB or TPC-H query.
Each query is essentially a left-deep chain of equality joins over simple tables. For reference, the structure is equivalent to:

 
15-table join

SELECT count(*)

FROM t1

JOIN t2 ON t1.id = t2.id

JOIN t3 ON t2.id = t3.id

 ...

JOIN t15 ON t14.id = t15.id;


20-table join

SELECT count(*)

FROM t1

JOIN t2 ON t1.id = t2.id

JOIN t3 ON t2.id = t3.id

...

JOIN t20 ON t19.id = t20.id;

Regarding planner settings:

-geqo_threshold was set to:

                 a high value (e.g., 100) to force DP

                 a low value (e.g., 2) to allow GEQO/GOO

-enable_goo_join_search was toggled on/off depending on the comparison being     measured.

-Other planner parameters, including join_collapse_limit, were left at their default values.

So these experiments mainly evaluate planning-time scaling and basic plan sanity on a controlled join graph, rather than realistic workload plan quality.

I’m currently preparing additional tests using selected JOB queries to provide more meaningful plan-quality comparisons and will share those results once available.
Regards
Lakshmi

pgsql-hackers by date:

Previous
From: Tomas Vondra
Date:
Subject: Re: Crash related to Shared Memory
Next
From: Soumya S Murali
Date:
Subject: Re: [Patch]Add tab completion for DELETE ... USING