Re: Parallel INSERT (INTO ... SELECT ...) - Mailing list pgsql-hackers

From Greg Nancarrow
Subject Re: Parallel INSERT (INTO ... SELECT ...)
Date
Msg-id CAJcOf-en-hL3U8mhZhpvy7xQqAUkYzB1G7Frr69wJqAkddtRSQ@mail.gmail.com
Whole thread Raw
In response to Re: Parallel INSERT (INTO ... SELECT ...)  (Zhihong Yu <zyu@yugabyte.com>)
Responses Re: Parallel INSERT (INTO ... SELECT ...)  (Zhihong Yu <zyu@yugabyte.com>)
List 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 by date:

Previous
From: Kyotaro Horiguchi
Date:
Subject: Re: parse mistake in ecpg connect string
Next
From: Zhihong Yu
Date:
Subject: Re: Parallel INSERT (INTO ... SELECT ...)