Re: CommandCounterIncrement versus plan caching - Mailing list pgsql-hackers

From Tom Lane
Subject Re: CommandCounterIncrement versus plan caching
Date
Msg-id 29457.1196555607@sss.pgh.pa.us
Whole thread Raw
In response to Re: CommandCounterIncrement versus plan caching  (Gregory Stark <stark@enterprisedb.com>)
List pgsql-hackers
Gregory Stark <stark@enterprisedb.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


pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: [PATCHES] Re: [GENERAL] plperl and regexps with accented characters - incompatible?
Next
From: Dragan Zubac
Date:
Subject: Stored procedure issue