On 18/7/2024 00:03, David Rowley wrote:
> On Wed, 17 Jul 2024 at 17:12, Andrei Lepikhov <lepihov(at)gmail(dot)com> wrote:
>> Also, I don't clearly understand the case you mentioned here - does it
>> mean that you want to nullify orders for other aggregate types if they
>> are the same as the incoming order?
>
> No, I mean unconditionally nullify Aggref->aggorder and
> Aggref->aggdistinct for aggregate functions where ORDER BY / DISTINCT
> in the Aggref makes no difference to the result. I think that's ok for
> max() and min() for everything besides NUMERIC. For aggorder, we'd
> have to *not* optimise sum() and avg() for floating point types as
> that could change the result. sum() and avg() for INT2, INT4 and INT8
> seems fine. I'd need to check, but I think sum(numeric) is ok too as
> the dscale should end up the same regardless of the order. Obviously,
> aggdistinct can't be changed for sum() and avg() on any type.
I have written a sketch patch to implement the idea with aggregate
prosupport in code - see the attachment.
My intention was to provide an example, not a ready-to-commit patch.
As I see, the only problem there lies in the tests - CREATE AGGREGATE
doesn't allow us to set a prosupport routine, and we need to update the
pg_proc table manually.
--
regards, Andrei Lepikhov