Re: Slow count(*) again...

Scott Carey <scott@richrelevance.com>

From: Scott Carey <scott@richrelevance.com>
To: "<david@lang.hm>" <david@lang.hm>
Cc: Craig Ringer <craig@postnewspapers.com.au>, Vitalii Tymchyshyn <tivv00@gmail.com>, "pgsql-performance@postgresql.org" <pgsql-performance@postgresql.org>
Date: 2010-10-12T16:46:08Z
Lists: pgsql-hackers, pgsql-performance
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 visibility under some circumstances.