Quick Links

pgsql: Avoid incrementing the CommandCounter when

Lists:	pgsql-committers

From:	tgl(at)postgresql(dot)org (Tom Lane)
To:	pgsql-committers(at)postgresql(dot)org
Subject:	pgsql: Avoid incrementing the CommandCounter when
Date:	2007-11-30 21:22:54
Message-ID:	20071130212254.DE7C47540F0@cvs.postgresql.org
Views:	Raw Message \| Whole Thread \| Download mbox \| Resend email
Lists:	pgsql-committers

Log Message:
-----------
Avoid incrementing the CommandCounter when CommandCounterIncrement is called
but no database changes have been made since the last CommandCounterIncrement.
This should result in a significant improvement in the number of "commands"
that can typically be performed within a transaction before hitting the 2^32
CommandId size limit. In particular this buys back (and more) the possible
adverse consequences of my previous patch to fix plan caching behavior.

The implementation requires tracking whether the current CommandCounter
value has been "used" to mark any tuples. CommandCounter values stored into
snapshots are presumed not to be used for this purpose. This requires some
small executor changes, since the executor used to conflate the curcid of
the snapshot it was using with the command ID to mark output tuples with.
Separating these concepts allows some small simplifications in executor APIs.

Something for the TODO list: look into having CommandCounterIncrement not do
AcceptInvalidationMessages. It seems fairly bogus to be doing it there,
but exactly where to do it instead isn't clear, and I'm disinclined to mess
with asynchronous behavior during late beta.

From:	Bruce Momjian <bruce(at)momjian(dot)us>
To:	Tom Lane <tgl(at)postgresql(dot)org>
Cc:	pgsql-committers(at)postgresql(dot)org
Subject:	Re: pgsql: Avoid incrementing the CommandCounter when
Date:	2008-03-17 22:59:10
Message-ID:	200803172259.m2HMxBX27887@momjian.us
Views:	Raw Message \| Whole Thread \| Download mbox \| Resend email
Lists:	pgsql-committers

Added to TODO:

* Consider if CommandCounterIncrement() can avoid its
AcceptInvalidationMessages() call

http://archives.postgresql.org/pgsql-committers/2007-11/msg00585.php

---------------------------------------------------------------------------

Tom Lane wrote:
> Log Message:
> -----------
> Avoid incrementing the CommandCounter when CommandCounterIncrement is called
> but no database changes have been made since the last CommandCounterIncrement.
> This should result in a significant improvement in the number of "commands"
> that can typically be performed within a transaction before hitting the 2^32
> CommandId size limit. In particular this buys back (and more) the possible
> adverse consequences of my previous patch to fix plan caching behavior.
>
> The implementation requires tracking whether the current CommandCounter
> value has been "used" to mark any tuples. CommandCounter values stored into
> snapshots are presumed not to be used for this purpose. This requires some
> small executor changes, since the executor used to conflate the curcid of
> the snapshot it was using with the command ID to mark output tuples with.
> Separating these concepts allows some small simplifications in executor APIs.
>
> Something for the TODO list: look into having CommandCounterIncrement not do
> AcceptInvalidationMessages. It seems fairly bogus to be doing it there,
> but exactly where to do it instead isn't clear, and I'm disinclined to mess
> with asynchronous behavior during late beta.
>
> Modified Files:
> --------------
> pgsql/contrib/pgrowlocks:
> pgrowlocks.c (r1.7 -> r1.8)
> (http://developer.postgresql.org/cvsweb.cgi/pgsql/contrib/pgrowlocks/pgrowlocks.c?r1=1.7&r2=1.8)
> pgsql/src/backend/access/heap:
> heapam.c (r1.245 -> r1.246)
> (http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/access/heap/heapam.c?r1=1.245&r2=1.246)
> tuptoaster.c (r1.79 -> r1.80)
> (http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/access/heap/tuptoaster.c?r1=1.79&r2=1.80)
> pgsql/src/backend/access/transam:
> xact.c (r1.253 -> r1.254)
> (http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/access/transam/xact.c?r1=1.253&r2=1.254)
> pgsql/src/backend/commands:
> async.c (r1.136 -> r1.137)
> (http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/commands/async.c?r1=1.136&r2=1.137)
> copy.c (r1.288 -> r1.289)
> (http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/commands/copy.c?r1=1.288&r2=1.289)
> explain.c (r1.167 -> r1.168)
> (http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/commands/explain.c?r1=1.167&r2=1.168)
> trigger.c (r1.224 -> r1.225)
> (http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/commands/trigger.c?r1=1.224&r2=1.225)
> pgsql/src/backend/executor:
> execMain.c (r1.300 -> r1.301)
> (http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/executor/execMain.c?r1=1.300&r2=1.301)
> execUtils.c (r1.152 -> r1.153)
> (http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/executor/execUtils.c?r1=1.152&r2=1.153)
> spi.c (r1.185 -> r1.186)
> (http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/executor/spi.c?r1=1.185&r2=1.186)
> pgsql/src/backend/storage/ipc:
> procarray.c (r1.37 -> r1.38)
> (http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/storage/ipc/procarray.c?r1=1.37&r2=1.38)
> pgsql/src/backend/utils/cache:
> inval.c (r1.81 -> r1.82)
> (http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/utils/cache/inval.c?r1=1.81&r2=1.82)
> pgsql/src/backend/utils/time:
> tqual.c (r1.107 -> r1.108)
> (http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/utils/time/tqual.c?r1=1.107&r2=1.108)
> pgsql/src/include/access:
> xact.h (r1.91 -> r1.92)
> (http://developer.postgresql.org/cvsweb.cgi/pgsql/src/include/access/xact.h?r1=1.91&r2=1.92)
> pgsql/src/include/commands:
> trigger.h (r1.63 -> r1.64)
> (http://developer.postgresql.org/cvsweb.cgi/pgsql/src/include/commands/trigger.h?r1=1.63&r2=1.64)
> pgsql/src/include/executor:
> executor.h (r1.144 -> r1.145)
> (http://developer.postgresql.org/cvsweb.cgi/pgsql/src/include/executor/executor.h?r1=1.144&r2=1.145)
> pgsql/src/include/nodes:
> execnodes.h (r1.181 -> r1.182)
> (http://developer.postgresql.org/cvsweb.cgi/pgsql/src/include/nodes/execnodes.h?r1=1.181&r2=1.182)
> pgsql/src/test/regress/expected:
> combocid.out (r1.1 -> r1.2)
> (http://developer.postgresql.org/cvsweb.cgi/pgsql/src/test/regress/expected/combocid.out?r1=1.1&r2=1.2)
> pgsql/src/test/regress/sql:
> combocid.sql (r1.1 -> r1.2)
> (http://developer.postgresql.org/cvsweb.cgi/pgsql/src/test/regress/sql/combocid.sql?r1=1.1&r2=1.2)
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: explain analyze is your friend

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://postgres.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +