Re: Improving count(*)

Поиск
Список
Период
Сортировка
От Jonah H. Harris
Тема Re: Improving count(*)
Дата
Msg-id 36e682920511171146y2db6fc4fh629a76c9e10b696f@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Improving count(*)  (Martijn van Oosterhout <kleptog@svana.org>)
Ответы Re: Improving count(*)  (Simon Riggs <simon@2ndquadrant.com>)
Список 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 по дате отправления:

Предыдущее
От: Martijn van Oosterhout
Дата:
Сообщение: Re: Improving count(*)
Следующее
От: "Kevin Grittner"
Дата:
Сообщение: Re: [ADMIN] ERROR: could not read block