Re: PL/PgSQL for counting all rows in all tables. - Mailing list pgsql-hackers

From Robert Treat
Subject Re: PL/PgSQL for counting all rows in all tables.
Date
Msg-id 200410121621.00346.xzilla@users.sourceforge.net
Whole thread Raw
In response to Re: PL/PgSQL for counting all rows in all tables.  ("Dave Page" <dpage@vale-housing.co.uk>)
Responses Re: PL/PgSQL for counting all rows in all tables.
Re: PL/PgSQL for counting all rows in all tables.
List pgsql-hackers
On Tuesday 12 October 2004 03:22, Dave Page wrote:
> > -----Original Message-----
> > From: Robert Treat [mailto:xzilla@users.sourceforge.net]
> > Sent: 11 October 2004 22:30
> > To: Dave Page
> > Cc: pgsql-hackers@postgresql.org
> > Subject: Re: [HACKERS] PL/PgSQL for counting all rows in all tables.
> >
> > How do you handle table growth that makes the reltuples value
> > out of whack since the last analyze?  Seems unfortunate that
> > people may not realize that the numbers they are looking at
> > are incorrect but I don't see much way to avoid it.
>
> Right-click the table object and select 'Count' on the current versions.
> Previously, iirc it showed the message 'Refresh table to count' in the
> actual count field, so you did a right-click -> Refresh.
>

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.  

BTW The reason I'm asking about this is we're trying to come up with a good 
scheme for phppgadmin to show estimated counts without showing incorrect 
numbers to users... or at least giving them a clue that the numbers might be 
really off. 

-- 
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL


pgsql-hackers by date:

Previous
From: "Dann Corbit"
Date:
Subject: Re: Hypothetical Indexes
Next
From: Bruce Momjian
Date:
Subject: Re: open item: tablespace handing in pg_dump/pg_restore