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
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 |
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.* |