From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | David Rowley <david(dot)rowley(at)2ndquadrant(dot)com> |
Cc: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: oversight in parallel aggregate |
Date: | 2016-04-05 14:39:53 |
Message-ID: | CA+TgmoaWrokpAepozGOXBzApmR_U4cAc0YYeWmkRMw-FYcMdwg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Apr 4, 2016 at 10:26 PM, David Rowley
<david(dot)rowley(at)2ndquadrant(dot)com> wrote:
> Does this need to check the parallel flags on the transfn or serialfn?
> these'll be executed on the worker process. Possibly we also need the
> combinefn/deserialfn/finalfn to be checked too as I see that we do
> generate_gather_paths() from set_append_rel_pathlist().
That's basically the same as Tom's question, I think. For right now,
I'd like to regard the aggregate function's pg_proc marking as
certifying that the entire aggregate can be trusted to be
parallel-safe. That's cheap and easy to check. If, in the future, we
want to allow more complicated things where some but not all of
aggregate's functions are parallel-safe, we can add logic for that
then - i.e. if the aggregate is labeled as parallel-restricted, then
inquire within. But to be honest, I hope we won't get there. As it
is, the list of things that you might want to do in an aggregate that
are parallel-unsafe is pretty short, and I hope we're going to go in
the direction of making even more things parallel-safe in the future.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Kapila | 2016-04-05 14:40:14 | Re: Support for N synchronous standby servers - take 2 |
Previous Message | Alvaro Herrera | 2016-04-05 14:38:27 | Re: Yet another small patch - reorderbuffer.c:1099 |