Re: Improving count(*) - Mailing list pgsql-hackers

From Jonah H. Harris
Subject Re: Improving count(*)
Date
Msg-id 36e682920511171146y2db6fc4fh629a76c9e10b696f@mail.gmail.com
Whole thread Raw
In response to Re: Improving count(*)  (Martijn van Oosterhout <kleptog@svana.org>)
Responses Re: Improving count(*)  (Simon Riggs <simon@2ndquadrant.com>)
List pgsql-hackers
Simon,
 
Nice suggestion, I think it's workable but (like all other methods) has some technical/pseudo-political challenges.
 
I'm still voting for my old, "Much Ado About COUNT(*)" topic; adding visibiility to the indexes and counting them like the other RDBMS vendors.  True, it would add storage overhead that several people don't want, but such as the life of the COUNT(*) discussion for PostgreSQL...
 
-Jonah

 
On 11/17/05, Martijn van Oosterhout <kleptog@svana.org> wrote:
On Thu, Nov 17, 2005 at 07:28:10PM +0000, Simon Riggs wrote:
> One of the major complaints is always "Select count(*) is slow".
>
> I have a somewhat broadbrush idea as to how we might do this (for larger
> tables).

It's an interesting idea, but you still run into the issue of
visibility. If two people start a transaction, one of them inserts a
row and then both run a select count(*), they should get different
answers. I just don't see a way that your suggestion could possibly
lead to that result...

There is no unique answer to count(*), it all depends on who is looking
(sounds like relativity :) ). If you can sort that, you're well over
90% of the way.

Have a nice day,
--
Martijn van Oosterhout   <kleptog@svana.org>   http://svana.org/kleptog/
> Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a
> tool for doing 5% of the work and then sitting around waiting for someone
> else to do the other 95% so you can sue them.



pgsql-hackers by date:

Previous
From: Martijn van Oosterhout
Date:
Subject: Re: Improving count(*)
Next
From: "Kevin Grittner"
Date:
Subject: Re: [ADMIN] ERROR: could not read block