Re: Slow count(*) again...
| От | Tom Lane | 
|---|---|
| Тема | Re: Slow count(*) again... | 
| Дата | |
| Msg-id | 4292.1286909893@sss.pgh.pa.us обсуждение исходный текст  | 
		
| Ответ на | Re: Slow count(*) again... (Jesper Krogh <jesper@krogh.cc>) | 
| Ответы | 
                	
            		Re: Slow count(*) again...
            		
            		 Re: Slow count(*) again...  | 
		
| Список | pgsql-performance | 
Jesper Krogh <jesper@krogh.cc> writes:
> On 2010-10-12 19:07, Tom Lane wrote:
>> Anyway, if anyone is hot to make COUNT(*) faster, that's where to look.
> Just having 32 bytes bytes of "payload" would more or less double
> you time to count if I read you test results correctly?. .. and in the
> situation where diskaccess would be needed .. way more.
> Dividing by pg_relation_size by the amout of tuples in our production
> system I end up having no avg tuple size less than 100bytes.
Well, yeah.  I deliberately tested with a very narrow table so as to
stress the per-row CPU costs as much as possible.  With any wider table
you're just going to be I/O bound.
> .. without having complete insigt.. a visibillity map that could be used in
> conjunction with indices would solve that. What the cost would be
> of maintaining it is also a factor.
I'm less than convinced that that approach will result in a significant
win.  It's certainly not going to do anything to convert COUNT(*) into
an O(1) operation, which frankly is what the complainants are expecting.
There's basically no hope of solving the "PR problem" without somehow
turning COUNT(*) into a materialized-view reference.  We've discussed
that in the past, and know how to do it in principle, but the complexity
and distributed overhead are daunting.
            regards, tom lane
		
	В списке pgsql-performance по дате отправления: