Re: [HACKERS] Aggregate transition state merging vs. hypothetical set functions
От | David Rowley |
---|---|
Тема | Re: [HACKERS] Aggregate transition state merging vs. hypothetical set functions |
Дата | |
Msg-id | CAKJS1f9oZeDB=gxYMDDjrTg3+6MF-NxqcLp1QmGxKmR3xPXBhA@mail.gmail.com обсуждение исходный текст |
Ответ на | [HACKERS] Aggregate transition state merging vs. hypothetical set functions (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [HACKERS] Aggregate transition state merging vs. hypothetical set functions
|
Список | pgsql-hackers |
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. > > The main thing that probably has to be hashed out before we can write > that patch is what the default should be for user-created aggregates. > I am inclined to think that we should err on the side of safety and > default it to false (no merge support). You could argue that the > lack of complaints since 9.6 came out is sufficient evidence that > defaulting to true would be all right, but I'm not sure. Are you considering that this is an option only for ordered-set aggregates or for 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. -- David Rowley http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services -- 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 по дате отправления: