Re: PL/PgSQL for counting all rows in all tables.

From: "Dave Page" <dpage(at)vale-housing(dot)co(dot)uk>
To: "Robert Treat" <xzilla(at)users(dot)sourceforge(dot)net>
Cc: <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: PL/PgSQL for counting all rows in all tables.
Date: 2004-10-13 07:45:33
Message-ID: E7F85A1B5FF8D44C8A1AF6885BC9A0E4306B33@ratbert.vale-housing.co.uk
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> -----Original Message-----
> From: Robert Treat [mailto:xzilla(at)users(dot)sourceforge(dot)net]
> Sent: 12 October 2004 21:21
> To: Dave Page
> Cc: pgsql-hackers(at)postgresql(dot)org
> Subject: Re: [HACKERS] PL/PgSQL for counting all rows in all tables.
>
> Maybe I didn't phrase that quite right. How would a user know
> that he needs to do a real count? For example, if I have a
> table with est 1 million rows, and I load another 1 million
> rows into it, wont pgadmin show me 1 million rows until I run
> an analyze? Even if I run a manual count, wont it show 1
> million next time I come into the application, and that time
> I may not realize that the table is off by 1 million rows so
> I take the estimated count at face value.

Yeah, that's exactly what can happen. If it makes you feel any better
about doing it in phppgadmin, then we never got any complaints about it!

We simply rely on the fact that it's labelled as an estimate. I can't
see that there's any other way around it that doesn't require running a
potentially very expensive ANALYZE to update the stats.

Regards, Dave

Browse pgsql-hackers by date

  From Date Subject
Next Message Neil Conway 2004-10-13 08:12:33 Re: plans for bitmap indexes?
Previous Message Leeuw van der, Tim 2004-10-13 06:32:22 Re: [HACKERS] open item: tablespace handing in pg_dump/pg_restore