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

On Mon, Jul 25, 2022 at 4:39 PM David Rowley <dgrowleyml(at)gmail(dot)com> wrote:

> On Fri, 22 Jul 2022 at 21:33, Richard Guo <guofenglinux(at)gmail(dot)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
>
Hi,

sort order the the planner chooses is simply : there is duplicate `the`

+ /* mark this aggregate is covered by 'currpathkeys'
*/

is covered by -> as covered by

Cheers