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

Поиск
Список
Период
Сортировка
От Josh Kupershmidt
Тема Re: docs update for count(*) and index-only scans
Дата
Msg-id CAK3UJRGTvO_z1Q6GJW=9LKQFBUXQTdJt7JP5RSBKP_UE+QznJQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: docs update for count(*) and index-only scans  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: docs update for count(*) and index-only scans  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-docs
On Tue, Nov 1, 2011 at 6:51 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Josh Kupershmidt <schmiddy@gmail.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

В списке pgsql-docs по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: docs update for count(*) and index-only scans
Следующее
От: Tom Lane
Дата:
Сообщение: Re: docs update for count(*) and index-only scans