Re: should INSERT SELECT use a BulkInsertState?

On Thu, Dec 03, 2020 at 10:59:34AM +0530, Bharath Rupireddy wrote:
> On Wed, Dec 2, 2020 at 10:24 PM Justin Pryzby <pryzby(at)telsasoft(dot)com> wrote:
> >
> > One loose end in this patch is how to check for volatile default expressions.
>
> I think we should be doing all the necessary checks in the planner and
> have a flag in the planned stmt to indicate whether to go with multi
> insert or not. For the required checks, we can have a look at how the
> existing COPY decides to go with either CIM_MULTI or CIM_SINGLE.

Yes, you can see that I've copied the checks from copy.
Like copy, some checks are done once, in ExecInitModifyTable, outside of the
ExecModifyTable "loop".

This squishes some commits together.
And uses bistate for ON CONFLICT.
And attempts to use memory context for tuple size.

For the bufferedBytes check, I'm not sure what's best. Copy flushes buffers
after 65k of input line length, but that's totally different from tuple slot
memory context size, which is what I used for insert. Maybe COPY should also
use slot size? Or maybe the threshold to flush needs to be set in miinfo,
rather than a #define, and differ between COPY and INSERT.

--
Justin