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: "Pavan Deolasee" <pavan(dot)deolasee(at)gmail(dot)com>
Cc: "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-03-31 15:32:43
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-generalpgsql-hackers
"Pavan Deolasee" <pavan(dot)deolasee(at)gmail(dot)com> writes:
> Seems like the redirected-dead line pointers are playing spoil-sport here.
> In this particular example, the deleted tuples may get truncated to
> redirected-dead line pointers. Analyze would report them as empty
> slots and not as dead tuples. So in the worst case, if all the deleted
> tuples are already truncated to redirected-dead line pointers, analyze
> may report "zero" dead tuple count.

[ Please see if you can stop using the "redirected dead" terminology ]

Yeah, I think I agree.  The page pruning code is set up so that changing
a line pointer to DEAD state doesn't change the count of dead tuples in
the table, so we are counting unreclaimed DEAD pointers as still being
dead tuples requiring VACUUM.  ANALYZE should surely not affect that.

It looks like there's no trivial way to get ANALYZE to do things that
way, though.  heap_release_fetch() doesn't distinguish a DEAD line
pointer from an unused or redirected one.  But in the current
implementation of ANALYZE there's really no benefit to using
heap_release_fetch anyway --- it always examines all line pointers
on each selected page, so we might as well rewrite it to use a simple
loop more like vacuum uses.

I notice that this'd leave heap_release_fetch completely unused...
at least in HEAD I'd be tempted to get rid of it and restore heap_fetch
to its former simplicity.

			regards, tom lane

In response to


pgsql-hackers by date

Next:From: Pavel StehuleDate: 2008-03-31 15:33:42
Subject: Fwd: WIP: CASE statement for PL/pgSQL
Previous:From: Tom LaneDate: 2008-03-31 14:58:46
Subject: Re: first time hacker ;) messing with prepared statements

pgsql-general by date

Next:From: Colin WetherbeeDate: 2008-03-31 15:54:14
Subject: Re: [pgsql-general] Daily digest v1.8030 (22 messages)
Previous:From: Pavel StehuleDate: 2008-03-31 15:29:25
Subject: Re: Array operator "sum array values"

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