Thanks for the answer it worked, the third analyze in the sequence below show
multiple workers planned and none launched.
PREPARE st AS SELECT avg(a) FROM parallel_big;
EXPLAIN ANALYZE EXECUTE st;
BEGIN;
SET TRANSACTION ISOLATION LEVEL READ COMMITTED, READ ONLY;
EXPLAIN ANALYZE EXECUTE st;
COMMIT;
BEGIN;
SET TRANSACTION ISOLATION LEVEL SERIALIZABLE, READ ONLY;
EXPLAIN ANALYZE EXECUTE st;
COMMIT;
DEALLOCATE st;
Cheers,
Luis M
From: Alvaro Herrera
Sent: Monday, February 12, 2018 4:19:52 PM
To: Luis Carril
Cc: pgsql-gene...@postgresql.org
Subject: Re: Trying to the behavior of a parallel query with with a change in
the transaction isolation mode
Luis Carril wrote:
> The transaction isolation level is serializable. This situation does not
> normally arise, because parallel query plans are not generated when the
> transaction isolation level is serializable. However, it can happen if the
> transaction isolation level is changed to serializable after the plan is
> generated and before it is executed.
> BEGIN;
> SET TRANSACTION ISOLATION LEVEL READ COMMITTED, READ ONLY;
> EXPLAIN (COSTS OFF) SELECT avg(a) FROM parallel_big;
> SET TRANSACTION ISOLATION LEVEL SERIALIZABLE, READ ONLY;
> EXPLAIN ANALYZE SELECT avg(a) FROM parallel_big;
> COMMIT;
>
>
> But complains that after the first SELECT (even if it is in an EXPLAIN)
> the isolation level cannot be changed, so the transaction is aborted and the
> SELECT is never executed (even sequentially).
>
>
> Is there any way to test the possible behavior described in the
> documentation?
I think you would do a PREPARE in a regular transaction, then open a
transaction changing the isolation level to serializable and try the
EXPLAIN EXECUTE there.
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services