Re: Slow count(*) again... - Mailing list pgsql-performance

From Scott Carey
Subject Re: Slow count(*) again...
Date
Msg-id AFE68F36-2B41-4065-A6EB-78C908FBEC95@richrelevance.com
Whole thread Raw
In response to Re: Slow count(*) again...  (Scott Carey <scott@richrelevance.com>)
List pgsql-performance
On Oct 12, 2010, at 9:46 AM, Scott Carey wrote:

>
> On Oct 12, 2010, at 8:54 AM, <david@lang.hm> wrote:
>
>> On Tue, 12 Oct 2010, Craig Ringer wrote:
>>
>>> On 10/12/2010 04:22 PM, david@lang.hm wrote:
>>>
>>>> from a PR point of view, speeding up the trivil count(*) case could be
>>>> worth it, just to avoid people complaining about it not being fast.
>>>
>>> At the cost of a fair bit more complexity, though, and slowing everything
>>> else down.
>>
>> complexity probably, although given how complex the planner is already is
>> this significant?
>>
>> as far as slowing everything else down, why would it do that? (beyond the
>> simple fact that any new thing the planner can do makes the planner take a
>> little longer)
>>
>> David Lang
>>
> I wouldn't even expect the planner to do more work.  An Index Scan can simply avoid going to the tuples for
visibilityunder some circumstances. 
>
>
Of course, the planner has to ....  Otherwise it won't choose the Index Scan over the sequential scan.  So the cost of
indexscans when all the info other than visibility is in the index would need to be lowered. 


> --
> Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-performance


pgsql-performance by date:

Previous
From: Scott Carey
Date:
Subject: Re: Slow count(*) again...
Next
From: Chris Browne
Date:
Subject: Re: large dataset with write vs read clients