| From: | Doug McNaught <doug(at)wireboard(dot)com> |
|---|---|
| To: | "Dann Corbit" <DCorbit(at)connx(dot)com> |
| Cc: | <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Suggestion for optimization |
| Date: | 2002-04-05 19:30:22 |
| Message-ID: | m3vgb6ymcx.fsf@varsoon.wireboard.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
"Dann Corbit" <DCorbit(at)connx(dot)com> writes:
> It would be nice if total table cardinality could be maintained live.
> So (after the initial vacuum) we update the cardinality for each table
> in the system table (or perhaps add an entry to the table itself).
> There are two reasons why this is an important optimization. Firstly,
> it is a psychological benefit for both benchmarks and customers when
> doing a select count(*) from <tablename>. This is something that pops
> up all the time in benchmarks and customers do it too, in order to get a
> feel for speed. By storing the current number and incrementing for
> every insert and decrementing for every delete, the count(*) case with
> no where clause can return the value instantly.
How would this work with MVCC?
-Doug
--
Doug McNaught Wireboard Industries http://www.wireboard.com/
Custom software development, systems and network consulting.
Java PostgreSQL Enhydra Python Zope Perl Apache Linux BSD...
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2002-04-05 19:37:19 | Re: Suggestion for optimization |
| Previous Message | Jan Wieck | 2002-04-05 19:22:02 | Re: timeout implementation issues |