On Tue, May 14, 2013 at 01:51:42PM +0900, Michael Paquier wrote: > On Mon, May 13, 2013 at 11:28 PM, Noah Misch <n...@leadboat.com> wrote: > > > * Identifying Parallel-Compatible Functions > > > > Not all functions can reasonably run on a worker backend. We should not > > presume that a VOLATILE function can tolerate the unstable execution order > > imposed by parallelism, though a function like clock_timestamp() is > > perfectly > > reasonable to run that way. STABLE does not have that problem, but neither > > does it constitute a promise that the function implementation is compatible > > with parallel execution. Consider xid_age(), which would need code > > changes to > > operate correctly in parallel. IMMUTABLE almost guarantees enough; there > > may > > come a day when all IMMUTABLE functions can be presumed parallel-safe. For > > now, an IMMUTABLE function could cause trouble by starting a (read-only) > > subtransaction. The bottom line is that parallel-compatibility needs to be > > separate from volatility classes for the time being. > > > I am not sure that this problem is only limited to functions, but to all > the expressions > and clauses of queries that could be shipped and evaluated on the worker > backends when > fetching tuples that could be used to accelerate a parallel sort. Let's > imagine for example > the case of a LIMIT clause that can be used by worker backends to limit the > number of tuples > to sort as final result.
It's true that the same considerations apply to other plan tree constructs; however, every such construct is known at build time, so we can study each one and decide how it fits with parallelism. Since functions are user-definable, it's preferable to reason about classes of functions. -- Noah Misch EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
