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

Re: Improvement of procArray.xmin for VACUUM

From: Heikki Linnakangas <heikki(at)enterprisedb(dot)com>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL-patches <pgsql-patches(at)postgresql(dot)org>
Subject: Re: Improvement of procArray.xmin for VACUUM
Date: 2007-03-24 10:19:27
Message-ID: 4604FB2F.3020706@enterprisedb.com (view raw or flat)
Thread:
Lists: pgsql-patches
Bruce Momjian wrote:
> Tom Lane wrote:
>> Bruce Momjian <bruce(at)momjian(dot)us> writes:
>>> I have been thinking we could improve how quickly VACUUM can expire rows
>>> if we update procArray.xmin more frequently for non-SERIALIZABLE
>>> transactions.
>>> The attached patch updates procArray.xmin in this manner.
>> This patch is incredibly broken.  Didn't you understand what I said
>> about how we don't track which snapshots are still alive?  You can't
>> advance procArray.xmin past the xmin of the oldest live snapshot in the
>> backend, and you can't assume that there are no live snapshots at the
>> places where this patch assumes that.  (Open cursors are one obvious
>> counterexample, but I think there are more.)
>>
>> To make intra-transaction advancing of xmin possible, we'd need to
>> explicitly track all of the backend's live snapshots, probably by
>> introducing a "snapshot cache" manager that gives out tracked refcounts
>> as we do for some other structures like catcache entries.  This might
>> have some other advantages (I think most of the current CopySnapshot
>> operations could be replaced by refcount increments) but it's a whole
>> lot more complicated and invasive than what you've got here.
> 
> I updated the patch to save the MyProc->xid at the time the first cursor
> is created, and not allow the MyProc->xid to be set lower than that
> saved value in the current transaction.  It added only a few more lines
> to the patch.

It seems to me a lot cleaner to do the reference counting like Tom 
suggested. Increase the refcount on CopySnapshot, and decrease it on 
FreeSnapshot. Assuming that all callers of CopySnapshot free the 
snapshot with FreeSnapshot when they're done with it.

BTW: I really like the idea of doing this. It's a relatively simple 
thing to do and gives some immediate benefit. And it opens the door for 
more tricks to vacuum more aggressively in the presence of long-running 
transactions. And it allows us to vacuum tuples that were inserted and 
deleted in the same transactions even while the transaction is still 
running, which helps some pathological cases where a transaction updates 
a counter column many times within a transaction. We could also use it 
to free entries in the new combocids hash table earlier (not that it's a 
problem as it is, though).

--
   Heikki Linnakangas
   EnterpriseDB   http://www.enterprisedb.com

In response to

Responses

pgsql-patches by date

Next:From: Tom LaneDate: 2007-03-24 15:48:22
Subject: Re: Improvement of procArray.xmin for VACUUM
Previous:From: Bruce MomjianDate: 2007-03-24 02:29:06
Subject: Re: Improvement of procArray.xmin for VACUUM

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