Re: Volatile Functions in Parallel Plans - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Volatile Functions in Parallel Plans
Date
Msg-id 3358896.1594912737@sss.pgh.pa.us
Whole thread Raw
In response to Re: Volatile Functions in Parallel Plans  (Jesse Zhang <sbjesse@gmail.com>)
Responses Re: Volatile Functions in Parallel Plans  (Jesse Zhang <sbjesse@gmail.com>)
List pgsql-hackers
Jesse Zhang <sbjesse@gmail.com> writes:
> You are right, no they are not consistent. But Neither plans is
> incorrect:

> 1. In the first query, it's semantically permissible to evaluate
> timeofday() for each pair of (c1, c2), and the plan reflects that.
> (Notice that the parallel nature of the plan is just noise here, the
> planner could have gone with a Nested Loop of which the inner side is
> _not_ materialized).

Yeah, exactly.  The short answer here is that refusing to parallelize
the plan would not make things any more consistent.

In general, using a volatile function in a WHERE clause is problematic
because we make no guarantees about how often it will be evaluated.
It could be anywhere between "never" and "once per row of the
cross-product of the FROM tables".  AFAIR, the only concession we've made
to make that less unpredictable is to avoid using volatile functions in
index quals.  But even that will only make things noticeably more
predictable for single-table queries.  As soon as you get into join cases,
you don't have much control over when the function will get evaluated.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Have SIGHUP instead of SIGTERM for config reload in logical replication launcher
Next
From: Bharath Rupireddy
Date:
Subject: Re: [PATCH] Performance Improvement For Copy From Binary Files