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

Re: ANALYZE getting dead tuple count hopelessly wrong

From: Gregory Stark <stark(at)enterprisedb(dot)com>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Simon Riggs" <simon(at)2ndquadrant(dot)com>, "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: ANALYZE getting dead tuple count hopelessly wrong
Date: 2008-04-01 19:18:18
Message-ID: 87lk3x5qpx.fsf@oxford.xeocode.com (view raw or flat)
Thread:
Lists: pgsql-generalpgsql-hackers
"Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

> 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.

I'm not sure all those arguments are valid (at least the first two seem
contradictory). However I'm skeptical about Simon's premise. It's not clear
any changes to ANALYZE here are at the expense of other proceses. Any cycles
saved in ANALYZE are available for those other processes after all...



-- 
  Gregory Stark
  EnterpriseDB          http://www.enterprisedb.com
  Get trained by Bruce Momjian - ask me about EnterpriseDB's PostgreSQL training!

In response to

pgsql-hackers by date

Next:From: Gregory StarkDate: 2008-04-01 19:20:51
Subject: Re: Scroll cursor oddity...
Previous:From: Simon RiggsDate: 2008-04-01 19:03:18
Subject: Re: Improve shutdown during online backup

pgsql-general by date

Next:From: BenDate: 2008-04-01 19:19:22
Subject: Re: Logging of autovacuum activity
Previous:From: Simon RiggsDate: 2008-04-01 19:14:39
Subject: Re: Logging of autovacuum activity

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