Skip site navigation (1) Skip section navigation (2)

Re: Select max(foo) and select count(*) optimization

From: "D'Arcy J(dot)M(dot) Cain" <darcy(at)druid(dot)net>
To: Shridhar Daithankar <shridhar_daithankar(at)persistent(dot)co(dot)in>,Postgresql Performance <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Select max(foo) and select count(*) optimization
Date: 2004-01-06 22:57:05
Message-ID: 200401061757.05278.darcy@druid.net (view raw or flat)
Thread:
Lists: pgsql-performance
On January 6, 2004 07:20 am, Shridhar Daithankar wrote:
> On Tuesday 06 January 2004 17:48, D'Arcy J.M. Cain wrote:
> > On January 6, 2004 01:42 am, Shridhar Daithankar wrote:
> > cert=# select relpages,reltuples::bigint from pg_class where relname=
> > 'certificate';
> >  relpages | reltuples
> > ----------+-----------
> >    399070 |  24858736
> > (1 row)
> >
> > But:
> >
> > cert=# select count(*) from certificate;
> > [*Crunch* *Crunch* *Crunch*]
> >   count
> > ----------
> >  19684668
> > (1 row)
> >
> > Am I missing something?  Max certificate_id is 20569544 btw.
>
> Do 'vacuum analyze certificate' and try..:-)

Kind of invalidates the part about being accurate then, don't it?  Besides, I 
vacuum that table every day (*) and we have reorganized the schema so that we 
never update it except in exceptional cases.  I would be less surprised if 
the result was less than the real count since we only insert into that table.

In any case, if I have to vacuum a 20,000,000 row table to get an accurate 
count then I may as well run count(*) on it.

(*): Actually I only analyze but I understand that that should be sufficient.

-- 
D'Arcy J.M. Cain <darcy(at){druid|vex}.net>   |  Democracy is three wolves
http://www.druid.net/darcy/                |  and a sheep voting on
+1 416 425 1212     (DoD#0082)    (eNTP)   |  what's for dinner.

In response to

Responses

pgsql-performance by date

Next:From: Tom LaneDate: 2004-01-06 23:12:35
Subject: Re: PgAdmin startup query VERY slow
Previous:From: Michael ShapiroDate: 2004-01-06 21:31:29
Subject: Re: PgAdmin startup query VERY slow

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group