Re: Allow parallel plan for referential integrity checks?
От | Frédéric Yhuel |
---|---|
Тема | Re: Allow parallel plan for referential integrity checks? |
Дата | |
Msg-id | 1d8d7291-09f1-2536-3a9a-89993ef4b63b@dalibo.com обсуждение исходный текст |
Ответ на | Re: Allow parallel plan for referential integrity checks? (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: Allow parallel plan for referential integrity checks?
|
Список | 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 по дате отправления: