Re: Sharing aggregate states between different aggregate functions - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: Sharing aggregate states between different aggregate functions
Date
Msg-id 55B7B62D.3030501@iki.fi
Whole thread Raw
In response to Re: Sharing aggregate states between different aggregate functions  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Sharing aggregate states between different aggregate functions  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On 07/28/2015 07:18 PM, Tom Lane wrote:
> Heikki Linnakangas <hlinnaka@iki.fi> writes:
>> On 07/28/2015 04:14 AM, David Rowley wrote:
>> Yeah, a volatile input function seems highly unlikely, but who knows.
>
> We have a project policy against volatile I/O functions.  One reason why
> is that it would break the assumption that record_in/record_out can be
> marked stable.  I think there are other reasons too.

Ok. In the latest patch I'm not relying that anyway, so it doesn't 
matter, but good to know.

>> BTW, we're also not checking if the transition or final functions are
>> volatile. But that was the same before this patch too.
>
> Up to now it hasn't mattered.

Yes, it has. We combine identical aggregates even without this patch. 
For example:

SELECT sum(x), sum(x) FROM foo

Sum(x) gets calculated only once. If its transition function or final 
function was volatile, that could produce two different results if we 
ran the aggregate twice.

No-one's complained so far, and I can't think of a use case for a 
volatile transition or final function, so maybe it's not worth worrying 
about. Then again, checking for the volatility of those functions would 
be easy too.

- Heikki




pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Re: Removing SSL renegotiation (Was: Should we back-patch SSL renegotiation fixes?)
Next
From: Tom Lane
Date:
Subject: Re: Sharing aggregate states between different aggregate functions