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

Re: Not HOT enough

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Simon Riggs <simon(at)2ndquadrant(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Not HOT enough
Date: 2011-11-23 19:57:06
Message-ID: CA+Tgmob=fNqBTzGVwBvJR7N1OmEKuhHaX-B=4sV_g2uyfxmyPA@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Wed, Nov 23, 2011 at 1:30 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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.  On a related note, Simon's
proposed change here would also complicate things for that patch,
because databaseId would have to become part of PGXACT rather than
PGPROC, and that would make the PGXACT act array larger and thus
slower to scan.  I have deep respect for the perils of not doing HOT
cleanup quickly enough, but ProcArrayLock contention is nothing to
sneeze at either.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

pgsql-hackers by date

Next:From: Simon RiggsDate: 2011-11-23 20:14:45
Subject: Re: Not HOT enough
Previous:From: Simon RiggsDate: 2011-11-23 19:33:18
Subject: Re: Not HOT enough

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