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:
min(citext)
max(citext)
int_array_aggregate(int4)
rewrite(tsquery[])
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.
Andreas
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
