On 06/02/2016 01:41 AM, Michael Paquier wrote:
> On Thu, Jun 2, 2016 at 7:36 AM, Andreas Karlsson <andr...@proxel.se> wrote: >> Looked at this quickly and I do not think adding it would be what I consider >> a small patch since we would essentially need to copy the validation logic
>> from DefineAggregate and AggregateCreate and modify it to fit the alter
>> case. I am leaning towards either either leaving the aggregate functions
>> alone or updating the catalog manually.
> As this is proving to be a hassle, what would it cost to leave those
> operator classes as-is for 9.6 and come up with a cleaner solution at
> DDL level with 10.0? Then we could still focus on the other extensions
> that have content that can be easily switched. That's more than 90% of
> the things that need to marked with parallel-safe.

I think at least three of the four aggregate functions are little used, so I do not think many users would be affected. And only min(citext) and max(citext) can make use of the parallel aggregation.

The functions are:


It would be nice if we had support for this in ALTER AGGREGATE in 9.6 already since I bet that there are external extensions which want to take advantage of the parallel aggregation, but at least if I add this command I do not feel like it would be a minor patch. If people disagree and are fine with copying the validation logic, then I am prepare to do the work. I would just rather not rush this if there is no chance anyway that it will get into 9.6.


Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to