| From: | Rod Taylor <pg(at)rbt(dot)ca> |
|---|---|
| To: | Steve Wampler <swampler(at)noao(dot)edu> |
| Cc: | pgsql-sql(at)postgresql(dot)org, Bruno Wolff III <bruno(at)wolff(dot)to> |
| Subject: | Re: Make COUNT(*) Faster? |
| Date: | 2005-07-08 15:22:30 |
| Message-ID: | 1120836150.24708.251.camel@home |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-sql |
> So, leave COUNT(*) alone. But it would be very handy to have a
> way to get an approximate table size that is more accurate than is
> provided by a pg_class.reltuples that is only updated on vacuums.
Create 2 sequences, one for counting tuple additions and one for
counting tuple deletions.
When you INSERT a tuple, bump the "added" sequence (select nextval());
When you DELETE a tuple, bump the "deleted" sequence (select nextval());
To retrieve an approximate count, take the current value of both
sequences (select directly -- don't use currval) and subtract the
"deletes" from the "adds".
This is a very fast tracking mechanism with the catch that it does not
handle rollbacks -- but you only wanted approximate. Put all of the
logic inside a pair of triggers and a function within the DB.
--
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Dawid Kuroczko | 2005-07-08 15:30:35 | Re: Make COUNT(*) Faster? |
| Previous Message | Steve Wampler | 2005-07-08 15:07:27 | Re: Make COUNT(*) Faster? |