Re: Add proper planner support for ORDER BY / DISTINCT aggregates
David Rowley <dgrowleyml@gmail.com>
From: David Rowley <dgrowleyml@gmail.com>
To: Ranier Vilela <ranier.vf@gmail.com>
Cc: PostgreSQL Developers <pgsql-hackers@lists.postgresql.org>
Date: 2021-07-13T04:44:12Z
Lists: pgsql-hackers
Attachments
- v3-0001-Add-planner-support-for-ORDER-BY-aggregates.patch (application/octet-stream) patch v3-0001
- v3-0002-WIP-Add-planner-support-for-DISTINCT-aggregates.patch (application/octet-stream) patch v3-0002
Thanks for having a look at this. On Tue, 13 Jul 2021 at 11:04, Ranier Vilela <ranier.vf@gmail.com> wrote: >> 0001 Adds planner support for ORDER BY aggregates. > > /* Normal transition function without ORDER BY / DISTINCT. */ > Is it possible to avoid entering to initialize args if 'argno >= pertrans->numTransInputs'? > Like this: > > if (!pertrans->aggsortrequired && argno < pertrans->numTransInputs) > > And if argos is '>' that pertrans->numTransInputs? > The test shouldn't be, inside the loop? > > + /* > + * Don't initialize args for any ORDER BY clause that might > + * exist in a presorted aggregate. > + */ > + if (argno >= pertrans->numTransInputs) > + break; The idea is to stop the loop before processing any Aggref arguments that might belong to the ORDER BY clause. We must still process other arguments up to the ORDER BY args though, so we can't skip this loop. Note that we're doing argno++ inside the loop. If we had a for_each_to() macro, similar to for_each_from(), but allowed us to specify an end element then we could use that instead, but we don't and we still must initialize the transition arguments. > I think that or can reduce the scope of variable 'sortlist' or simply remove it? I've adjusted the scope of this. I didn't want to remove it because it's kinda useful to have it that way otherwise the 0002 patch would need to add it. >> 0002 is a WIP patch for DISTINCT support. This still lacks JIT >> support and I'm still not certain of the best where to store the >> previous value or tuple to determine if the current one is distinct >> from it. > > In the patch 0002, I think that can reduce the scope of variable 'aggstate'? > > + EEO_CASE(EEOP_AGG_PRESORTED_DISTINCT_SINGLE) Yeah, that could be done. I've attached the updated patches. David
Commits
-
Don't presort ORDER BY/DISTINCT Aggrefs with volatile functions
- da5800d5fa63 16.0 landed
-
Add enable_presorted_aggregate GUC
- 3226f47282a0 16.0 landed
-
Remove pessimistic cost penalization from Incremental Sort
- 4a29eabd1d91 16.0 landed
-
Fix hypothetical problem passing the wrong GROUP BY pathkeys
- af7d270dd3c7 16.0 landed
-
Remove unused fields from ExprEvalStep
- 9fc1776dda9f 16.0 landed
-
Improve performance of ORDER BY / DISTINCT aggregates
- 1349d2790bf4 16.0 landed
-
Refactor function parse_subscription_options.
- 8aafb0261675 15.0 cited