Re: Large DB

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Manfred Koizar <mkoi-pg(at)aon(dot)at>
Cc: "Mooney, Ryan" <ryan(dot)mooney(at)pnl(dot)gov>, pgsql-general(at)postgresql(dot)org
Subject: Re: Large DB
Date: 2004-04-01 15:22:19
Message-ID: 29257.1080832939@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

Manfred Koizar <mkoi-pg(at)aon(dot)at> writes:
> Hackers, what could update reltuples, but not relpages?

Nothing --- they are always updated together. One possibility is that
the 4M pages and 290M rows numbers really do go together (for about 112
bytes/row) and that the table has since grown, or perhaps merely bloated
due to lack of vacuuming of updated rows.

A different line of thought is that they were updated together, but the
relpages estimate was accurate while reltuples was not. ANALYZE knows
the actual table size in pages (because it asks the OS) but reltuples is
extrapolated from an average of the number of live tuples on the pages
ANALYZE looks at. It is possible for ANALYZE to be fooled badly if, for
instance, there are lots and lots of dead rows near the start of the
table. (Lack of regular vacuuming would certainly improve the odds of
this happening...)

Note that VACUUM is not subject to this error because it has to grovel
over every page anyway. So either "VACUUM" or "VACUUM ANALYZE" will
give you a known-good reltuples, it's only standalone "ANALYZE" that
has a risk of estimation error.

regards, tom lane

In response to

Browse pgsql-general by date

  From Date Subject
Next Message weiping he 2004-04-01 15:26:16 A simple question about Read committed isolation level
Previous Message John Liu 2004-04-01 15:08:53 Re: select distinct w/order by

Browse pgsql-hackers by date

  From Date Subject
Next Message Tony Reina 2004-04-01 17:52:11 Re: pgmex, a MATLAB interface for PostgreSQL
Previous Message Tom Lane 2004-04-01 14:20:03 Re: with vs without oids in pg_catalog.*