On Tue, Jul 5, 2011 at 2:35 PM, Kevin Grittner <kevin.gritt...@wicourts.gov> wrote: >> It'd be better to push some functionality into the procarray code. > > That's easily done if we don't mind taking out a ProcArrayLock > during completion of a transaction which has no XID, if only long > enough to increment a uint64 in shared memory, and then stash the > value -- somewhere -- so that SSI code can find and use it.
That sure sounds scary from a scalability perspective. If we can piggyback on an existing ProcArrayLock acquisition, fine, but additional ProcArrayLock acquisitions when SSI isn't even being used sound like a real bad idea to me. I doubt you'll notice much of a performance regression in the current code, but if/when we fix the lock manager bottlenecks that my fastlock and lazy vxid lock patches are intended to correct, then I suspect it's going to matter quite a bit. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
