From: | Frédéric Yhuel <frederic(dot)yhuel(at)dalibo(dot)com> |
---|---|
To: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Allow parallel plan for referential integrity checks? |
Date: | 2022-03-03 14:12:46 |
Message-ID: | 1d8d7291-09f1-2536-3a9a-89993ef4b63b@dalibo.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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(dot)yhuel(at)dalibo(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Brar Piening | 2022-03-03 14:17:12 | Re: Add id's to various elements in protocol.sgml |
Previous Message | Pavel Borisov | 2022-03-03 13:47:43 | Re: Problem with moderation of messages with patched attached. |