On Fri, Dec 2, 2011 at 4:11 PM, Kevin Grittner
<Kevin.Grittner@wicourts.gov> wrote:
> As far as I'm concerned it looks great and "Ready for Committer"
> except for the modularity/pluggability question. Perhaps that could
> be done as a follow-on patch (if deemed a good idea)?
I investigated the performance issues with the previous version of the
patch and found that turning some of the FlexLock support functions
into macros seems to help quite a bit, so I've done that in the
attached versions. I've also incorporated Kevin's incremental patch
from his previous version.
That having been said, I'm leaning away from applying any of this for
the time being. For one thing, Pavan's PGXACT stuff has greatly
eroded the benefit of this patch. I'm fairly optimistic about the
prospects of finding other good uses for the FlexLock machinery down
the road, but I don't feel like that's enough reason to apply it now.
Also, there are several other good ideas kicking around out there for
further reducing ProcArrayLock contention, some of which are
lower-impact than this and others of which would obsolete the entire
approach. So it seems like I should probably let the dust settle on
those things before deciding whether this even makes sense. In
particular, I'm starting to think that resolving the contention
between GetSnapshotData() and ProcArrayEndTransaction() is basically a
layup at this point, and I really want to go for a three-pointer,
namely also eliminating the spinlock contention between different
backends all trying to acquire ProcArrayLock in shared mode during
read-only operation.
So, I'm going to mark this Returned with Feedback for now and keep
working on the problem. Thanks for the review and positive comments.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
