Re: Allow parallel plan for referential integrity checks? - Mailing list pgsql-hackers

From Frédéric Yhuel
Subject Re: Allow parallel plan for referential integrity checks?
Date
Msg-id 1d8d7291-09f1-2536-3a9a-89993ef4b63b@dalibo.com
Whole thread Raw
In response to Re: Allow parallel plan for referential integrity checks?  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Allow parallel plan for referential integrity checks?  ("Imseih (AWS), Sami" <simseih@amazon.com>)
List pgsql-hackers
Hello, sorry for the late reply.

On 2/14/22 15:33, Robert Haas wrote:
> On Mon, Feb 7, 2022 at 5:26 AM Frédéric Yhuel <frederic.yhuel@dalibo.com> wrote:
>> I noticed that referential integrity checks aren't currently
>> parallelized. Is it on purpose?
> 
> It's not 100% clear to me that it is safe. But on the other hand, it's
> also not 100% clear to me that it is unsafe.
> 
> Generally, I only added CURSOR_OPT_PARALLEL_OK in places where I was
> confident that nothing bad would happen, and this wasn't one of those
> places. It's something of a nested-query environment -- your criterion
> #6. How do we know that the surrounding query isn't already parallel?
> Perhaps because it must be DML,

Did you mean DDL?

> but I think it must be more important
> to support parallel DML than to support this.


> I'm not sure what the right thing to do here is, but I think it would
> be good if your patch included a test case.
> 

Would that be a regression test? (in src/test/regress ?)

If yes, what should I check? Is it good enough to load auto_explain and 
check that the query triggered by a foreign key addition is parallelized?

Best regards,
Frédéric



pgsql-hackers by date:

Previous
From: Pavel Borisov
Date:
Subject: Re: Problem with moderation of messages with patched attached.
Next
From: Brar Piening
Date:
Subject: Re: Add id's to various elements in protocol.sgml