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 plan to continue testing with more realistic workloads and will share
further results if anything notable appears.
Thanks for the interesting work.
Regards,
Lakshmi
On Fri, Feb 13, 2026 at 12:33 PM Pavel Stehule <[email protected]>
wrote:
>
>
> čt 11. 12. 2025 v 18:07 odesílatel Tomas Vondra <[email protected]> napsal:
>
>> On 12/11/25 07:12, Pavel Stehule wrote:
>> >
>> >
>> > čt 11. 12. 2025 v 3:53 odesílatel John Naylor <[email protected]
>> > <mailto:[email protected]>> napsal:
>> >
>> > On Wed, Dec 10, 2025 at 5:20 PM Tomas Vondra <[email protected]
>> > <mailto:[email protected]>> 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.
>> >
>>
>> Depends on what you mean by "really complex". TPC-DS queries are not
>> trivial, but the complexity may not be in the number of joins.
>>
>> Of course, setting geqo_threshold to 2 may be too aggressive. Not sure.
>>
>
> I checked the TPC-H queries and almost all queries are simple - 5 x JOIN
> -- 2x nested subselect
>
>
>>
>>
>> regards
>>
>> --
>> Tomas Vondra
>>
>>
