Re: [HACKERS] Aggregate transition state merging vs. hypothetical set functions - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [HACKERS] Aggregate transition state merging vs. hypothetical set functions
Date
Msg-id 6042.1507851674@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] Aggregate transition state merging vs. hypothetical set functions  (David Rowley <david.rowley@2ndquadrant.com>)
Responses Re: [HACKERS] Aggregate transition state merging vs. hypothetical set functions
Re: [HACKERS] Aggregate transition state merging vs. hypothetical set functions
List pgsql-hackers
David Rowley <david.rowley@2ndquadrant.com> writes:
> On 13 October 2017 at 12:08, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Therefore, I think we need to bite the bullet and provide an aggregate
>> property (CREATE AGGREGATE argument / pg_aggregate column) that tells
>> whether the aggregate supports transition state merging.  Likely this
>> should have been in the state-merging patch to begin with, but better
>> late than never.

> Are you considering that this is an option only for ordered-set
> aggregates or for all?

All.

> If the user defines their normal aggregate as not safe for merging,
> then surely it'll not be suitable to be used as a window function
> either, since the final function will also be called there multiple
> times per state.

Yeah, we would probably also want to check the flag in nodeWindowAgg.
Not sure exactly how that should play out --- maybe we end up with
a tri-valued property "works as normal agg without merging, works
as normal agg with merging, works as window agg".  But this would
arguably be an improvement over the current situation.  Right now
I'm sure there are user-written aggs out there that will just crash
if used as a window agg, and the authors don't have much choice because
the performance costs of not modifying the transition state in the
finalfn are higher than they're willing to bear.  At least with a
flag they could ensure that the case will fail cleanly.
        regards, tom lane


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: [HACKERS] [PATCH] pageinspect function to decode infomasks
Next
From: Tom Lane
Date:
Subject: Re: [HACKERS] oversight in EphemeralNamedRelation support