On Fri, Oct 3, 2025 at 3:41 AM Matheus Alcantara
<matheusssilv97@gmail.com> wrote:
> Thanks for all the details. I've disabled the nested loops and executed
> the benchmark again and the results look much better! I see a 55%
> improvement on query_31 on my machine now (MacOS M3 Max).
Great! That is 2.23 times faster.
> The only query that I see a considerable regression is query 23 which I
> get a 23% worst execution time. I'm attaching the EXPLAIN(ANALYZE)
> output from master and from the patched version if it's interesting.
I tested query 23 in my local environment but didn't observe the
regression.
-- on master
Planning Time: 1.950 ms
Execution Time: 3260.924 ms
-- on patched
Planning Time: 2.197 ms
Execution Time: 3237.287 ms
I ran the benchmark at scale factor 1 and executed ANALYZE beforehand.
For the build configuration, I disabled cassert.
Comparing the plans, I noticed one key difference: in the plan you
provided (query-23.patch.explain), the frequent_ss_items CTE uses
parallel aggregation, whereas in my local environment it does not.
This leads to a different final join order between the two plans.
However, given the highly inaccurate size and cost estimates for the
CTE Scan nodes, I'm not sure it's worth investigating further. I'm
starting to feel that trying to tune performance here, with such
inaccurate underlying estimates for CTEs, is like building on sand.
> I'm also attaching a csv with the planning time and execution time from
> master and the patched version for all queries. It contains the % of
> difference between the executions. Negative numbers means that the
> patched version using eager aggregation is faster. (I loaded this csv on
> a postgres table and played with some queries to analyze the results).
I really appreciate this; it's very helpful.
> I'm just wondering if there is anything that can be done on the planner
> to prevent this type of situation?
I think the ideal solution is to improve our estimates for CTE
relations to make the plans for TPC-DS queries more reasonable. Of
course, for queries from other benchmarks, the issues may stem from
other plan nodes. IMHO, we really need some improvements in our cost
estimation.
- Richard
