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
|
Список | 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 по дате отправления: