From: Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>
To: Kevin Grittner <Kevin.Grittner@wicourts.gov>
Cc: pgsql-hackers@postgresql.org
Subject: Re: SSI modularity questions
Date: Tue, 28 Jun 2011 09:44:47 +0300
Message-ID: <4E09785F.8050004@enterprisedb.com> (raw)
In-Reply-To: <4E08846E020000250003EC69@gw.wicourts.gov>
References: <4E08846E020000250003EC69@gw.wicourts.gov>
On 27.06.2011 21:23, Kevin Grittner wrote:
> 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:
>
> http://archives.postgresql.org/message-id/20110622045850.GN83336@csail.mit.edu
>
> 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.
The bigger question is if those calls are needed at all
(http://archives.postgresql.org/message-id/4E072EA9.3030200@enterprisedb.com).
I'm uneasy about changing them this late in the release cycle, but I
don't feel good about leaving useless clutter in place just because
we're late in the release cycle either. More importantly, if locking the
whole relation in a seqscan is not just a performance optimization, but
is actually required for correctness, it's important that we make the
code and comments to reflect that or someone will break it in the future.
> (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:
>
> http://archives.postgresql.org/message-id/4E07550F020000250003EC42@gw.wicourts.gov
>
> 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
> grounds.
>
> If these two places were moved, there would be no SSI calls from any
> source file in the executor subdirectory.
Same here, we might not need those PredicateLockTuple calls in bitmap
heap scan at all. Can you check my logic, and verify if those
PredicateLockTuple() calls are needed?
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: heikki.linnakangas@enterprisedb.com, Kevin.Grittner@wicourts.gov
Subject: Re: SSI modularity questions
In-Reply-To: <4E09785F.8050004@enterprisedb.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox