Skip site navigation (1) Skip section navigation (2)

SSI modularity questions

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: <pgsql-hackers(at)postgresql(dot)org>
Subject: SSI modularity questions
Date: 2011-06-27 18:23:58
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
There are two outstanding patches for SSI which involve questions
about modularity.  In particular, they involve calls to predicate
locking and conflict detection from executor source files rather
than AM source files (where most such calls exist).
(1)  Dan submitted this patch:
which is a very safe and very simple patch to improve performance on
sequential heap scans at the serializable transaction isolation
level.  The location of the code being modified raised questions
about modularity.  There is a reasonably clear place to which it
could be moved in the heap AM, but because it would acquire a
predicate lock during node setup, it would get a lock on the heap
even if the node was never used, which could be a performance
regression in some cases.
(2)  In reviewing the above, Heikki noticed that there was a second
place in the executor that SSI calls were needed but missing.  I
submitted a patch here:
I wonder, though, whether the section of code which I needed to
modify should be moved to a new function in heapam.c on modularity
If these two places were moved, there would be no SSI calls from any
source file in the executor subdirectory.
Should these be moved before beta3?


pgsql-hackers by date

Next:From: Robert HaasDate: 2011-06-27 18:25:32
Subject: Re: pg_upgrade defaulting to port 25432
Previous:From: Bruce MomjianDate: 2011-06-27 18:19:26
Subject: Re: pg_upgrade defaulting to port 25432

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group