Hello,
On 2/13/26 12:14, lakshmi wrote:
> HI all,
> I tested the latest GOO patch (v4) on a fresh build from the current
> PostgreSQL master. The patch applied cleanly, the server built without
> issues, and regression tests passed except for the expected EXPLAIN
> output differences due to the new join ordering behavior.
>
> As a quick sanity check, I compared DP, GEQO, and GOO on a small multi-
> join query:
>
> DP planning: ~0.66 ms
> GEQO planning: ~2.28 ms
> GOO planning: ~0.38 ms
> Execution times were similar across all three (~1.5–1.7 ms) with no
> correctness issues. Even on a small join, GEQO shows higher planning
> overhead, while GOO plans faster with comparable execution cost.
> I then evaluated scaling using synthetic 15-table and 20-table joins
> with EXPLAIN (ANALYZE, TIMING OFF):
> 15 tables
> DP: ~22.9 ms | ~23.4 ms
> GEQO: ~46.7 ms | ~20.5 ms
> GOO: ~1.8 ms | ~22.4 ms
>
> 20 tables
> DP: ~48.1 ms | ~30.5 ms
> GEQO: ~51.0 ms | ~26.7 ms
> GOO: ~3.2 ms | ~29.0 ms
>
> Planning time increases notably for DP and remains relatively high for
> GEQO, while GOO stays very low even at 20 joins, indicating substantially
> reduced planning overhead. Execution costs remain broadly comparable,
> with no obvious regressions from GOO in this synthetic workload.
>
> Although this uses a controlled synthetic join graph rather than JOB/
> TPC-H, the scaling behavior appears consistent with GOO’s goal of
> significantly cheaper planning than DP/GEQO while preserving similar
> plan quality.
>
I think we need to know much more about the synthetic benchmark to judge
the plan quality. For example, for OLTP-like schema/queries, processing
only very few rows in each join, the different join methods are likely
to perform about the same. The performance will differ for larger joins
(matching large number of rows / large intermediate results).
The other question is whether the plans produced by the join search
algorithms even differ.
regards
--
Tomas Vondra
