On Wed, Nov 23, 2011 at 8:45 PM, Robert Haas <robertmh...@gmail.com> wrote:
> I've wondered a few times whether we could get rid of the > RecentGlobalXmin computation from GetSnapshotData() altogether. You have to calculate an xmin, so its unavoidable. My patch actually improves the speed of snapshots, rather than slowing them as Tom's would. > We > think that it's cheap to do it there because we already hold > ProcArrayLock in exclusive mode, but Pavan's work suggests that it > really isn't that cheap. Instead of updating RecentGlobalXmin every > time we take a snapshot (which is likely to be a waste in many cases, > since even in a busy system many snapshots are very short lived and > therefore unlikely to trigger a HOT cleanup) maybe we should only > update it "on demand" - e.g. if heap_page_prune_opt sees a > page-prune-hint XID that is older than TransactionXmin and newer than > the last-computed value of RecentGlobalXmin, there's hope that a > recomputation might yield a new RecentGlobalXmin value new enough to > allow a HOT cleanup, so if we haven't recomputed it "lately", then we > should. When we prune a page while running an UPDATE if we see that the page is left with less freespace than average row length for that relation AND page sees a RecentlyDead xid we could then re-derive a later db-local cutoff value and re-prune the page. That increases page lock time, but pages are locked for longer if we do non-HOT updates anyway, so it would still be a win. What % of non-HOT updates do you see in your recent benchmarks? -- 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
