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 <alvhe...@alvh.no-ip.org> 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 Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
