From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Kevin Grittner <kgrittn(at)gmail(dot)com>, Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Allow parallelism for deferrable serializable txns |
Date: | 2018-09-06 19:14:51 |
Message-ID: | 20180906191451.pjrnkjmpzdvov62k@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
The code currently says:
* We can't use parallelism in serializable mode because the predicate
* locking code is not parallel-aware. It's not catastrophic if someone
* tries to run a parallel plan in serializable mode; it just won't get
* any workers and will run serially. But it seems like a good heuristic
* to assume that the same serialization level will be in effect at plan
* time and execution time, so don't generate a parallel plan if we're in
* serializable mode.
*/
if ((cursorOptions & CURSOR_OPT_PARALLEL_OK) != 0 &&
IsUnderPostmaster &&
parse->commandType == CMD_SELECT &&
!parse->hasModifyingCTE &&
max_parallel_workers_per_gather > 0 &&
!IsParallelWorker() &&
!IsolationIsSerializable())
{
/* all the cheap tests pass, so scan the query tree */
glob->maxParallelHazard = max_parallel_hazard(parse);
glob->parallelModeOK = (glob->maxParallelHazard != PROPARALLEL_UNSAFE);
}
afaict for deferrable READ ONLY DEFERRABLE transactions we could
trivially allow parallelism? Am I missing something?
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2018-09-06 19:22:27 | Re: Prevent concurrent DROP SCHEMA when certain objects are being initially created in the namespace |
Previous Message | Peter Eisentraut | 2018-09-06 19:01:14 | Re: Collation versioning |