Re: [HACKERS] ANALYZE getting dead tuple count hopelessly wrong

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Simon Riggs <simon(at)2ndquadrant(dot)com>
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 count hopelessly wrong
Date: 2008-04-01 14:22:03
Message-ID: 1678.1207059723@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

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 haven't read the patch yet, but I'm inclined to go with the design
Pavan suggests.

regards, tom lane

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Tom Lane 2008-04-01 14:27:06 Re: simple update queries take a long time - postgres 8.3.1
Previous Message Morris Goldstein 2008-04-01 14:12:15 Re: Can Postgres 8.x start if some disks containing tablespaces are not mounted?

Browse pgsql-hackers by date

  From Date Subject
Next Message Dave Cramer 2008-04-01 14:26:52 Re: [HACKERS] How embarrassing: optimization of a one-shot query doesn't work
Previous Message Michael Paesold 2008-04-01 14:21:34 Re: [HACKERS] How embarrassing: optimization of a one-shot query doesn't work