Re: Slow count(*) again...

On Oct 12, 2010, at 9:46 AM, Scott Carey wrote:

>
> On Oct 12, 2010, at 8:54 AM, <david(at)lang(dot)hm> wrote:
>
>> On Tue, 12 Oct 2010, Craig Ringer wrote:
>>
>>> On 10/12/2010 04:22 PM, david(at)lang(dot)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 visibility under some circumstances.
>
>
Of course, the planner has to .... Otherwise it won't choose the Index Scan over the sequential scan. So the cost of index scans when all the info other than visibility is in the index would need to be lowered.

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