Re: Sharing aggregate states between different aggregate functions

From: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Sharing aggregate states between different aggregate functions
Date: 2015-07-28 17:04:45
Message-ID: 55B7B62D.3030501@iki.fi
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 07/28/2015 07:18 PM, Tom Lane wrote:
> Heikki Linnakangas <hlinnaka(at)iki(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2015-07-28 17:19:30 pgsql: Improve logging of TAP tests.
Previous Message Andres Freund 2015-07-28 17:00:01 Re: Re: Removing SSL renegotiation (Was: Should we back-patch SSL renegotiation fixes?)