Re: Add proper planner support for ORDER BY / DISTINCT aggregates

Поиск
Список
Период
Сортировка
От David Rowley
Тема Re: Add proper planner support for ORDER BY / DISTINCT aggregates
Дата
Msg-id CAApHDvr3JQv4_H7vfu5Djtw0ubKwGDwvNtPuphtaQY4utgj7bQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Add proper planner support for ORDER BY / DISTINCT aggregates  (Richard Guo <guofenglinux@gmail.com>)
Ответы Re: Add proper planner support for ORDER BY / DISTINCT aggregates  (Zhihong Yu <zyu@yugabyte.com>)
Re: Add proper planner support for ORDER BY / DISTINCT aggregates  (Richard Guo <guofenglinux@gmail.com>)
Список pgsql-hackers
On Fri, 22 Jul 2022 at 21:33, Richard Guo <guofenglinux@gmail.com> wrote:
> 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.

Yeah, you're right. I have a missing check to see if currpathkeys are
better than the pathkeys for the current aggregate. In your example
case we'd have still processed the 2nd aggregate the old way instead
of realising we could take the new pre-sorted path for faster
processing.

I've adjusted that in the attached to make it properly include the
case where currpathkeys are better.

Thanks for the review.

David

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Peter Smith
Дата:
Сообщение: Re: Handle infinite recursion in logical replication setup
Следующее
От: Zhihong Yu
Дата:
Сообщение: Re: Add proper planner support for ORDER BY / DISTINCT aggregates