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

From David Rowley
Subject Re: [HACKERS] Aggregate transition state merging vs. hypothetical set functions
Date
Msg-id CAKJS1f9oZeDB=gxYMDDjrTg3+6MF-NxqcLp1QmGxKmR3xPXBhA@mail.gmail.com
Whole thread Raw
In response to [HACKERS] Aggregate transition state merging vs. hypothetical set functions  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [HACKERS] Aggregate transition state merging vs. hypothetical set functions
List pgsql-hackers
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.
>
> The main thing that probably has to be hashed out before we can write
> that patch is what the default should be for user-created aggregates.
> I am inclined to think that we should err on the side of safety and
> default it to false (no merge support).  You could argue that the
> lack of complaints since 9.6 came out is sufficient evidence that
> defaulting to true would be all right, but I'm not sure.

Are you considering that this is an option only for ordered-set
aggregates or for 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.


-- David Rowley                   http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services


-- 
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: Tom Lane
Date:
Subject: [HACKERS] Aggregate transition state merging vs. hypothetical set functions
Next
From: Thomas Munro
Date:
Subject: Re: [HACKERS] oversight in EphemeralNamedRelation support