Re: Parallel INSERT (INTO ... SELECT ...)
| От | Greg Nancarrow |
|---|---|
| Тема | Re: Parallel INSERT (INTO ... SELECT ...) |
| Дата | |
| Msg-id | CAJcOf-en-hL3U8mhZhpvy7xQqAUkYzB1G7Frr69wJqAkddtRSQ@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Parallel INSERT (INTO ... SELECT ...) (Zhihong Yu <zyu@yugabyte.com>) |
| Ответы |
Re: Parallel INSERT (INTO ... SELECT ...)
|
| Список | pgsql-hackers |
On Fri, Feb 12, 2021 at 2:33 PM Zhihong Yu <zyu@yugabyte.com> wrote: > > For v17-0001-Enable-parallel-SELECT-for-INSERT-INTO-.-SELECT.patch : > > + /* Assume original queries have hasModifyingCTE set correctly */ > + if (parsetree->hasModifyingCTE) > + hasModifyingCTE = true; > > Since hasModifyingCTE is false by the time the above is run, it can be simplified as: > hasModifyingCTE = parsetree->hasModifyingCTE > Actually, we should just return parsetree->hasModifyingCTE at this point, because if it's false, we shouldn't need to continue the search (as we're assuming it has been set correctly for QSRC_ORIGINAL case). > + if (!hasSubQuery) > + return false; > + > + return true; > > The above can be simplified as: > return hasSubQuery; > Yes, absolutely right, silly miss on that one! Thanks. This was only ever meant to be a temporary fix for this bug that affects this patch. Regards, Greg Nancarrow Fujitsu Australia
В списке pgsql-hackers по дате отправления: