On Wed, Nov 23, 2011 at 8:15 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> On Wed, Nov 23, 2011 at 1:30 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >>> What I think might make more sense is to keep two variables, >>> RecentGlobalXmin with its current meaning and RecentDatabaseWideXmin >>> which considers only xmins of transactions in the current database. >>> Then HOT cleanup could select the appropriate cutoff depending on >>> whether it's working on a shared or non-shared relation. > >> Unfortunately, that would have the effect of lengthening the time for >> which ProcArrayLock is held, and as benchmark results from Pavan's >> patch in that area show, that makes a very big difference to total >> throughput on write-heavy workloads. > > [ shrug... ] Simon's patch already adds nearly as many cycles in the > hot spot as would be required to do what I suggest.
Well, its deeper than that. My patch actually skips xids that aren't in the user's database. That avoids other work in GetSnapshotData(), so will in many cases make it faster. The snapshots returned will be smaller, which also means more speed. As you point out upthread, that generates an MVCC snapshot that is not safe for user queries against shared catalog tables. Standard catalog access is safe, but user access isn't. The way to solve that problem is to make all scans against shared catalog tables use SnapshotNow, whatever the snapshot says. Which would be more useful since you'll see exactly what the DBMS sees. Given the infrequency of change to those tables and the infrequency of user access to those tables it seems like a very good thing. If we do as you suggest, snapshots would contain all xids from all databases, so no effort would be skipped, but we would pay the cost of deriving two values just in case we ever decide to read a shared catalog table, which is blue moon frequency, so a net loss. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers