Skip site navigation (1) Skip section navigation (2)

Re: Not HOT enough

From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Not HOT enough
Date: 2011-11-23 21:36:46
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Wed, Nov 23, 2011 at 8:45 PM, Robert Haas <robertmhaas(at)gmail(dot)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         
 PostgreSQL Development, 24x7 Support, Training & Services

In response to


pgsql-hackers by date

Next:From: Tom LaneDate: 2011-11-23 21:39:35
Subject: Re: range_adjacent and discrete ranges
Previous:From: Tom LaneDate: 2011-11-23 21:10:04
Subject: Re: range_adjacent and discrete ranges

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group