Re: pgadmin3 and partitionned tables

On Monday 10 April 2006 15:18, you wrote:
> Marc Cousin wrote:
> > all the databases of the cluster are regularly vacuumed (at least once a
> > day), all the stats are up to date.
>
> If stats say 0 ("estimated rows") rows but 40M rows are present stats
> are clearly not up-to-date. We had interpretation problems of
> pg_class.reltuples because it was read as int, not as float, but that
> was fare earlier than 1.4.
> If SELECT reltuples FROM pg_class WHERE relname='<foo>' returns
> non-zero, but estimated rows is 0, your platform's strtod might have a
> locale problem, but I doubt that because from my observations pgsql will
> always return [1-9].[0-9](n)e[1-9](n), i.e. if the decimal point was the
> problem est. rowcount would be between 1 and 9.
>

0 rows are effectively present in the table. That's the whole point...
The table contains 0 rows, but there are several tables that inherit from this 
one. And those table contain the real rows.

So the stats say 0 rows on the main table, and they are right.

But pgadmin does a select count on this table, so postgres sums the rows from 
this table and all the inheriting tables too.