From: | Marc Cousin <mcousin(at)sigma(dot)fr> |
---|---|
To: | pgadmin-support(at)postgresql(dot)org |
Subject: | Re: pgadmin3 and partitionned tables |
Date: | 2006-04-10 13:25:28 |
Message-ID: | 200604101525.28260.mcousin@sigma.fr |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgadmin-support |
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.
From | Date | Subject | |
---|---|---|---|
Next Message | Andreas Pflug | 2006-04-10 13:37:14 | Re: pgadmin3 and partitionned tables |
Previous Message | Andreas Pflug | 2006-04-10 13:18:04 | Re: pgadmin3 and partitionned tables |