Re: Error when using array_agg with filter where clause in pg16 and pg17

David Rowley <dgrowleyml(at)gmail(dot)com> writes:
> On Wed, 9 Apr 2025 at 12:25, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Oooh. If the FILTER clause is selective, that could easily mean that
>> the "optimization" loses big from having to sort many more tuples.
>> I wonder if we should just not apply it when there's a FILTER,
>> full stop.

> The only way I can see to fix that properly is to cost it in during
> aggregate planning. IIRC, there's no costing for the implicit sorts in
> Aggref. We could add some of those and put a flag in AggPath which
> gets propagated to Agg to specify if aggpresorted should be ignored or
> not for the given Agg node. We'd have to add_path() for both versions
> of the AggPath and let the cheapest Path win.

Yeah, AFAIR we never did any real costing of aggregate-internal
sorting. However, adding that would pose the same risk you mentioned
that some queries might regress due to picking the worse plan.

> I suspect we should just leave this for v18 and maybe come back and
> improve for v19.

I think not doing anything is unacceptable: even though it took awhile
to notice, presorted_agg flat out breaks some queries that worked
before. That trumps any worries about "maybe the plan will be worse",
and I don't even think it's a close decision. So my inclination is
to do the simplest possible thing in v16-v18, and that seems to be
to disable presorted_agg if there's a FILTER. Then we can look
into better ideas at leisure for v19.

regards, tom lane