Re: CommandCounterIncrement versus plan caching

Gregory Stark <stark(at)enterprisedb(dot)com> writes:
> ExecutorStart could also determine when the query is a "write-only" query for
> which the provided command id won't be used for any snapshot checks (ie, a
> simple INSERT) and tell CCI not to bump the CCI if the previous CC even if
> it's dirty.

Ummm ... I'm not convinced about that. ExecutorStart doesn't have any
cheap way of inspecting the query carefully (eg, to see if it invokes
volatile functions), nor any understanding of what context the query is
being called in (eg, inside a subtransaction or volatile function).

> That would eliminate the other big use case where users can run out of
> command ids, batch inserts.

If you're planning to insert 4 billion rows without using COPY (or at
least multi-VALUES inserts), you've got more patience than I do.

regards, tom lane