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 по дате отправления:

Предыдущее
От: Kyotaro Horiguchi
Дата:
Сообщение: Re: parse mistake in ecpg connect string
Следующее
От: Zhihong Yu
Дата:
Сообщение: Re: Parallel INSERT (INTO ... SELECT ...)