Re: docs update for count(*) and index-only scans

On Tue, Nov 1, 2011 at 6:51 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Josh Kupershmidt <schmiddy(at)gmail(dot)com> writes:
>> func.sgml still claims that a sequential scan is the only way to
>> execute a SELECT COUNT(*) query. I think this note should just be
>> removed from the current docs, given the existence of index-only
>> scans; patch attached.
>
> Well, it might need adjustment, but I don't think we should remove it
> outright.  The people who complain that COUNT(*) is not O(1) are still
> going to be complaining.  On tables that are not read-mostly, there's
> no reason to expect that index-only scans will even provide a material
> speed boost, let alone be close to free.

Yeah, that's all true. I'd be OK with an adjustment along the lines of
"note: COUNT(*) can be expensive, use judiciously".

But the tone of the existing note suggests that users "may be
surprised" that our COUNT(*) is slower than other RDBMSs. So I guess
I'm wondering, are we really still that much slower than our
competitors for COUNT(*)? Ignoring MyISAM and similar lobotomized
engines, does any competitor have a much-faster way?

Josh