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

Re: [HACKERS] ANALYZE getting dead tuple counthopelessly wrong

From: Simon Riggs <simon(at)2ndquadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Pavan Deolasee <pavan(dot)deolasee(at)gmail(dot)com>, Stuart Brooks <stuartb(at)cat(dot)co(dot)za>, pgsql-general(at)postgresql(dot)org, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [HACKERS] ANALYZE getting dead tuple counthopelessly wrong
Date: 2008-04-01 14:46:15
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-generalpgsql-hackers
On Tue, 2008-04-01 at 10:22 -0400, Tom Lane wrote:
> Simon Riggs <simon(at)2ndquadrant(dot)com> writes:
> > On Tue, 2008-04-01 at 13:07 +0530, Pavan Deolasee wrote:
> >> Please see the attached patch. One change I made is to hold the SHARE lock
> >> on the page while ANALYZE is reading tuples from it. I thought it would
> >> be a right thing to do instead of repeatedly acquiring/releasing the lock.
> > ANALYZE is a secondary task and so we shouldn't be speeding it up at the
> > possible expense of other primary tasks. So I think holding locks for
> > longer than minimum is not good in this case and I see no reason to make
> > the change described.
> I think Pavan's change is probably good.  In the first place, it's only
> a shared buffer lock and besides ANALYZE isn't going to be holding it
> long (all it's doing at this point is counting tuples and copying some
> of them into memory).  In the second place, repeated lock release and
> re-grab threatens cache line contention and a context swap storm if
> there is anyone else trying to access the page. In the third, whether
> there's contention or not the extra acquire/release work will cost CPU
> cycles.  In the fourth, if we actually believed this was a problem we'd
> need to redesign VACUUM too, as it does the same thing.

VACUUM waits until nobody else has the buffer pinned, so lock contention
is much less of a consideration there. Plus it rearranges the block,
which is hard to do one tuple at a time even if we wanted to.

  Simon Riggs

  PostgreSQL UK 2008 Conference:

In response to


pgsql-hackers by date

Next:From: Tom LaneDate: 2008-04-01 14:50:32
Subject: Re: build multiple indexes in single table pass?
Previous:From: PFCDate: 2008-04-01 14:43:58
Subject: Re: [HACKERS] How embarrassing: optimization of a one-shot query doesn't work

pgsql-general by date

Next:From: Ivan Sergio BorgonovoDate: 2008-04-01 14:54:12
Subject: optimiser STABLE vs. temp table was: HOWTO caching data across function calls: temporary tables, cursor?
Previous:From: Adrian KlaverDate: 2008-04-01 14:29:34
Subject: Re: Using tables in other PostGreSQL database

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