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

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 15:00:15
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-generalpgsql-hackers
Simon Riggs <simon(at)2ndquadrant(dot)com> writes:
> On Tue, 2008-04-01 at 10:22 -0400, Tom Lane wrote:
>> 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.

That's the second scan.  The first scan acts exactly like Pavan is
proposing for ANALYZE.

			regards, tom lane

In response to

pgsql-hackers by date

Next:From: Mathias HasselmannDate: 2008-04-01 15:07:31
Subject: Re: [HACKERS] Avahi support for Postgresql
Previous:From: Tom LaneDate: 2008-04-01 14:52:41
Subject: Re: Scroll cursor oddity...

pgsql-general by date

Next:From: Pettis, BarryDate: 2008-04-01 15:12:54
Subject: Re: Using tables in other PostGreSQL database
Previous: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?

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