Tom,
Ok, but how about reading from temporary tables? We could mark the function as
"PARALLEL SAFE” instead of "PARALLEL RESTRICTED” in this case if it’s
important. Actually, I rewrote the function without temp tables access but
that’s not helpful - the function marked as "PARALLEL SAFE” is not
mobigroup writes:
>> Perhaps you didn't define it as PARALLEL SAFE.
> The function is marked as "PARALLEL RESTRICTED” because it’s uses temp tables
> (and I tested it as PARALLEL SAFE with the same result… parallelisation
> doesn’t work anyway).
If it writes into temp tables then it can't be r
Thanks for the ideas, I tested them:
>
> The essential question here is when the function is executed, so you should
> use
> EXPLAIN (VERBOSE) to see that.
Append (cost=0.00..5.12 rows=4 width=32)
-> Gather (cost=0.00..1.26 rows=1 width=32)
Output: plpgsql_function(...)
Work
On Tue, 2020-12-01 at 14:38 +0700, mobigroup wrote:
> I have strange behaviour when EXPLAIN returns parallel execution plan but the
> query execution is not parallel. The query looks as
>
> SELECT
> plpgsql_function(...parameters…)
> FROM table as t
> WHERE id=
Hi,
I have strange behaviour when EXPLAIN returns parallel execution plan but the
query execution is not parallel. The query looks as
SELECT
plpgsql_function(...parameters…)
FROM table as t
WHERE id=1
UNION ALL
SELECT
plpgsql_functi
