Re: Add proper planner support for ORDER BY / DISTINCT aggregates
От | Richard Guo |
---|---|
Тема | Re: Add proper planner support for ORDER BY / DISTINCT aggregates |
Дата | |
Msg-id | CAMbWs49hcB-Mj3MJTOesL5=y4oU+md=zEvDYdCBrOSaDvXLRGQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Add proper planner support for ORDER BY / DISTINCT aggregates (David Rowley <dgrowleyml@gmail.com>) |
Ответы |
Re: Add proper planner support for ORDER BY / DISTINCT aggregates
|
Список | pgsql-hackers |
On Wed, Jul 20, 2022 at 1:27 PM David Rowley <dgrowleyml@gmail.com> wrote:
I've been working on this patch again. There was a bit of work to do
to rebase it atop db0d67db2. The problem there was that since this
patch appends pathkeys to suit ORDER BY / DISTINCT aggregates to the
query's group_pathkeys, db0d67db2 goes and tries to rearrange those,
but fails to find the SortGroupClause corresponding to the PathKey in
group_pathkeys. I wish the code I came up with to make that work was a
bit nicer, but what's there at least seems to work. There are a few
more making copies of Lists than I'd like.
record we've found pathkeys for an aggregate, because 'currpathkeys' may
include pathkeys for some latter aggregates. I can see this problem with
the query below:
select max(b order by b), max(a order by a) from t group by a;
When processing the first aggregate, we compose the 'currpathkeys' as
{a, b} and mark this aggregate in 'aggindexes'. When it comes to the
second aggregate, we compose its pathkeys as {a} and decide that it is
not stronger than 'currpathkeys'. So the second aggregate is not
recorded in 'aggindexes'. As a result, we fail to mark aggpresorted for
the second aggregate.
Thanks
Richard
В списке pgsql-hackers по дате отправления: