Re: Parallel INSERT (INTO ... SELECT ...)

On Tue, Jan 19, 2021 at 1:37 PM tsunakawa(dot)takay(at)fujitsu(dot)com
<tsunakawa(dot)takay(at)fujitsu(dot)com> wrote:
>
> > The table has ALREADY been locked (by the caller) during the
> > parse/analyze phase.
>
> Isn't there any case where planning is done but parse analysis is not done immediately before? e.g.
>
> * Alteration of objects invalidates cached query plans, and the next execution of the plan rebuilds it. (But it seems that parse analysis is done in this case in plancache.c.)
>
> * Execute a prepared statement with a different parameter value, which builds a new custom plan or a generic plan.
>

I don't know, but since NoLock is used in other parts of the planner,
I'd expect those to fail if such cases existed.

> Is the cached query plan invalidated when some alteration is done to change the parallel safety, such as adding a trigger with a parallel-unsafe trigger action?
>

Needs to be tested, but I'd expect the cached plan to get invalidated
in this case - surely the same potential issue exists in Postgres for
the current Parallel SELECT functionality - for example, for a column
with a default value that is an expression (which could be altered
from being parallel-safe to parallel-unsafe).

Regards,
Greg Nancarrow
Fujitsu Australia