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

Re: Possible TODO item? VACUUM on empty table

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Greg Stark <gsstark(at)mit(dot)edu>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Possible TODO item? VACUUM on empty table
Date: 2004-11-26 18:48:34
Message-ID: 10380.1101494914@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Greg Stark <gsstark(at)mit(dot)edu> writes:
> But not all of the stats are simple totals. I'm not sure this would make sense
> for the histogram arrays.

Yeah, I don't know how you "halve" a histogram.

But the problem is not with the pg_statistic stats, I think.  It is
already true that ANALYZE punts without touching pg_statistic if it was
unable to find any live rows, and AFAIR it always has.  So the problem
case of delete all/analyze doesn't clobber pg_statistic.

The issue is only with the relpages and reltuples counts in pg_class.
I already have a proposal on the table to get rid of these in favor of
a "tuples per page" entry, see eg
http://archives.postgresql.org/pgsql-general/2004-08/msg01422.php

An objection that I forgot to mention in that message is that any such
change would break autovacuum in its current form; although that issue
largely vanishes if we integrate autovacuum into the backend, and in any
case we could offer a built-in function to return the current number of
pages in a table.

			regards, tom lane

In response to

pgsql-hackers by date

Next:From: Tom LaneDate: 2004-11-26 19:10:49
Subject: Re: Question to tea leaf readers
Previous:From: Yann MichelDate: 2004-11-26 15:07:37
Subject: Re: Bitmap index

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