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
|
Список | 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 по дате отправления: