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

Re: Improvement of procArray.xmin for VACUUM

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Simon Riggs <simon(at)2ndquadrant(dot)com>, Heikki Linnakangas <heikki(at)enterprisedb(dot)com>, PostgreSQL-patches <pgsql-patches(at)postgresql(dot)org>
Subject: Re: Improvement of procArray.xmin for VACUUM
Date: 2007-03-26 21:07:18
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-patches
This is an optimization so I was thinking of something simpler, like 
incrementing/decrementing a counter every time we allocate/free a
snapshot (like in the patch), and updating MyProc->xmin only if there
are no open snapshots.  I don't think it is worth tracking anything more
complicated than that.  Is that now possible to do cleanly?  I am having
trouble getting this to work in the attached patch.


Tom Lane wrote:
> Bruce Momjian <bruce(at)momjian(dot)us> writes:
> > Simon Riggs wrote:
> >> How much does it cost to optimise for this case?
> > Zero cost.  It involves just tracking if there are any old snapshots,
> I will be fascinated to hear how you define that as zero cost.  It might
> be relatively low, but it's not zero, and for many simple cases (eg,
> all single-statement transactions) the benefit will indeed be zero.
> We need some serious consideration of the costs and benefits, not airy
> dismissals.
> I had originally thought that we could avoid CopySnapshot copying,
> which might buy back more than enough to cover the cost of tracking
> reference counts ... but in a quick look yesterday it seemed that the
> high-use code paths would still need a copy, because they are always
> copying off the static variables filled by GetTransactionSnapshot.
> Changing that would come with a tremendous memory penalty, or else
> a time penalty to scan the ProcArray twice to see how big the arrays
> need to be.
> [ thinks a bit... ]  The other way we might possibly tackle that is
> to avoid copying by the expedient of just using those static snapshot
> variables in-place.  SerializableSnapshot surely need never be copied
> since it remains unchanged till end of xact, and no use of the snap
> will survive longer than that.  In simple cases LatestSnapshot is not
> overwritten until the prior value is no longer needed, either.  If
> we could arrange to copy it only when setting up a cursor, or other
> long-lived usage, we'd be ahead of the game.  But I'd certainly want
> a management layer in there to ensure that we don't overwrite a value
> that *is* still in use, and offhand I'm not sure what that layer would
> need to look like.  Possibly some sort of double indirection so that
> callers would have a Snapshot pointer that remained valid after we'd
> copied off arrays that need to be updated?  We already do have double
> indirection in the form of the Snapshot and xip[] pointers ... maybe
> attach refcounts to the xip arrays not the Snapshots per se?
> 			regards, tom lane
> ---------------------------(end of broadcast)---------------------------
> TIP 1: if posting/reading through Usenet, please send an appropriate
>        subscribe-nomail command to majordomo(at)postgresql(dot)org so that your
>        message can get through to the mailing list cleanly

  Bruce Momjian  <bruce(at)momjian(dot)us>

  + If your life is a hard drive, Christ can be your backup. +

Attachment: /pgpatches/xid
Description: text/x-diff (18.5 KB)

In response to


pgsql-patches by date

Next:From: Jeremy DrakeDate: 2007-03-26 21:59:18
Subject: Re: [pgsql-patches] [HACKERS] less privileged pl install
Previous:From: Tom LaneDate: 2007-03-26 20:25:32
Subject: Re: Improvement of procArray.xmin for VACUUM

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