Re: Volatile Functions in Parallel Plans

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Volatile Functions in Parallel Plans
Дата
Msg-id 3358896.1594912737@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Volatile Functions in Parallel Plans  (Jesse Zhang <sbjesse@gmail.com>)
Ответы Re: Volatile Functions in Parallel Plans  (Jesse Zhang <sbjesse@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Have SIGHUP instead of SIGTERM for config reload in logical replication launcher
Следующее
От: Bharath Rupireddy
Дата:
Сообщение: Re: [PATCH] Performance Improvement For Copy From Binary Files