Thanks,
Then how to explain relpages
(size_kb in result returned)?
SELECT relname, relpages * 8 as size_kb,
relfilenode, reltuples
FROM pg_class c1
WHERE relkind = 'r'
AND relname = 'my_tab';
relname | size_kb | relfilenode | reltuples
------------------+---------+-------------+-----------
my_tab | 30088 | 266181583 | 165724
analyze my_tab;
relname | size_kb | relfilenode | reltuples
------------------+---------+-------------+-------------
my_tab | 2023024 | 266181583 |
1.12323e+07
vacuum my_tab;
SELECT relname, relpages * 8 as size_kb,
relfilenode, reltuples
FROM pg_class c1
WHERE relkind = 'r'
AND relname = 'my_tab';
relname | size_kb | relfilenode | reltuples
------------------+---------+-------------+-----------
my_tab | 2038016 | 266181583 | 189165
(1 row)
--- Tom Lane <[EMAIL PROTECTED]> wrote:
> Litao Wu <[EMAIL PROTECTED]> writes:
> > I noticed that reltuples are way off if
> > I vacuum the table and analyze the table.
> > And the data (296901) after vacuum seems
> > accurate while
> > the reltuples (1.90744e+06)
> > after anlayze is too wrong.
>
> VACUUM derives an exact count because it scans the
> whole table. ANALYZE
> samples just a subset of the table and extrapolates.
> It would appear
> that you've got radically different tuple densities
> in different parts
> of the table, and that's confusing ANALYZE.
>
> > My PG version is 7.3.2 (I know it is old).
>
> 8.0's ANALYZE uses a new sampling method that we
> think is less prone
> to this error, though of course any sampling method
> will fail some of
> the time.
>
> regards, tom lane
>
__________________________________
Do you Yahoo!?
Yahoo! Mail - Find what you need with new enhanced search.
http://info.mail.yahoo.com/mail_250
---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings
