Re: [HACKERS] Aggregate transition state merging vs. hypothetical set functions

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [HACKERS] Aggregate transition state merging vs. hypothetical set functions
Дата
Msg-id 6042.1507851674@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [HACKERS] Aggregate transition state merging vs. hypothetical set functions  (David Rowley <david.rowley@2ndquadrant.com>)
Ответы Re: [HACKERS] Aggregate transition state merging vs. hypothetical set functions  (David Rowley <david.rowley@2ndquadrant.com>)
Re: [HACKERS] Aggregate transition state merging vs. hypothetical set functions  (Heikki Linnakangas <hlinnaka@iki.fi>)
Список pgsql-hackers
David Rowley <david.rowley@2ndquadrant.com> writes:
> 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.

> Are you considering that this is an option only for ordered-set
> aggregates or for all?

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.

Yeah, we would probably also want to check the flag in nodeWindowAgg.
Not sure exactly how that should play out --- maybe we end up with
a tri-valued property "works as normal agg without merging, works
as normal agg with merging, works as window agg".  But this would
arguably be an improvement over the current situation.  Right now
I'm sure there are user-written aggs out there that will just crash
if used as a window agg, and the authors don't have much choice because
the performance costs of not modifying the transition state in the
finalfn are higher than they're willing to bear.  At least with a
flag they could ensure that the case will fail cleanly.
        regards, tom lane


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

Предыдущее
От: Peter Geoghegan
Дата:
Сообщение: Re: [HACKERS] [PATCH] pageinspect function to decode infomasks
Следующее
От: Tom Lane
Дата:
Сообщение: Re: [HACKERS] oversight in EphemeralNamedRelation support