Re: Sharing aggregate states between different aggregate functions

Поиск
Список
Период
Сортировка
От Heikki Linnakangas
Тема Re: Sharing aggregate states between different aggregate functions
Дата
Msg-id 55B7B62D.3030501@iki.fi
обсуждение исходный текст
Ответ на Re: Sharing aggregate states between different aggregate functions  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Sharing aggregate states between different aggregate functions  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: Re: Removing SSL renegotiation (Was: Should we back-patch SSL renegotiation fixes?)
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Sharing aggregate states between different aggregate functions