Re: Eager aggregation, take 3 - Mailing list pgsql-hackers

From Richard Guo
Subject Re: Eager aggregation, take 3
Date
Msg-id CAMbWs49E_dR0nobsExsyetpnBpHObLTsQLsEbWKQLkh0omPxNg@mail.gmail.com
Whole thread Raw
In response to Re: Eager aggregation, take 3  (Richard Guo <guofenglinux@gmail.com>)
Responses Re: Eager aggregation, take 3
List pgsql-hackers

On Tue, Mar 5, 2024 at 7:19 PM Richard Guo <guofenglinux@gmail.com> wrote:
Here is another rebase, mainly to make the test cases more stable by
adding ORDER BY clauses to the test queries.  Also fixed more typos in
passing.

This needs another rebase after 97d85be365.  I also addressed several
issues that I identified during self-review, which include:

* In some cases GroupPathExtraData.agg_final_costs, which is the cost of
final aggregation, fails to be calculated.  This can lead to bogus cost
estimation and end up with unexpected plan.

* If the cheapest partially grouped path is generated through eager
aggregation, the number of groups estimated for the final phase will be
different from the number of groups estimated for non-split aggregation.
That is to say, we should not use 'dNumGroups' for the final aggregation
in add_paths_to_grouping_rel().

* It is possible that we may generate dummy grouped join relations, and
that would trigger the Assert in make_grouped_join_rel().

* More typo fixes.

Thanks
Richard
Attachment

pgsql-hackers by date:

Previous
From: John Naylor
Date:
Subject: Re: [PoC] Improve dead tuple storage for lazy vacuum
Next
From: Amit Kapila
Date:
Subject: Re: Introduce XID age and inactive timeout based replication slot invalidation