Allow parallel plan for referential integrity checks?

From: Frédéric Yhuel <frederic(dot)yhuel(at)dalibo(dot)com>
To: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Allow parallel plan for referential integrity checks?
Date: 2022-02-07 10:26:07
Message-ID: 0d21e3b4-dcde-290c-875e-6ed5013e8e52@dalibo.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hello,

I noticed that referential integrity checks aren't currently
parallelized. Is it on purpose?

From the documentation [1], the planner will not generate a parallel
plan for a given query if any of the following are true:

1) The system is running in single-user mode.
2) max_parallel_workers_per_gather = 0.
3) The query writes any data or locks any database rows.
4) The query might be suspended during execution (cursor or PL/pgSQL loop).
5) The query uses any function marked PARALLEL UNSAFE.
6) The query is running inside of another query that is already parallel.

From my understanding of the code, it seems to me that the fourth
condition is not always accurately detected. In particular, the query
triggered by a foreign key addition (a Left Excluding JOIN between the
two tables) isn't parallelized, because the flag CURSOR_OPT_PARALLEL_OK
hasn't been set at some point. I couldn't find any reason why not, but
maybe I missed something.

Attached is a (naive) patch that aims to fix the case of a FK addition,
but the handling of the flag CURSOR_OPT_PARALLEL_OK, generally speaking,
looks rather hackish.

Best regards,
Frédéric

[1]
https://www.postgresql.org/docs/current/when-can-parallel-query-be-used.html

Attachment Content-Type Size
0001-Allow-parallel-plan-for-referential-integrity-checks.patch text/x-patch 1.4 KB

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Julien Rouhaud 2022-02-07 10:29:47 Re: Database-level collation version tracking
Previous Message Yugo NAGATA 2022-02-07 10:14:18 Re: Fix CheckIndexCompatible comment