Re: So, is COUNT(*) fast now?
| От | Tom Lane |
|---|---|
| Тема | Re: So, is COUNT(*) fast now? |
| Дата | |
| Msg-id | 29572.1319222011@sss.pgh.pa.us обсуждение исходный текст |
| Ответ на | Re: So, is COUNT(*) fast now? (Robert Haas <robertmhaas@gmail.com>) |
| Ответы |
Re: So, is COUNT(*) fast now?
|
| Список | pgsql-hackers |
Robert Haas <robertmhaas@gmail.com> writes:
> On Fri, Oct 21, 2011 at 2:08 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> What this test case proves is that btree's overhead per index
>> tuple touched is significantly more than the cost of the fastest path
>> through HeapTupleSatisfiesMVCC, which I don't find surprising
>> considering how much sweat has been expended on that code path over the
>> years.
> I think HeapTupleSatisfiesMVCC is probably being skipped anyway in
> this case, since all the heap pages should be PD_ALL_VISIBLE.
Proves my point ;-) ... you're comparing a code path that's been beat on
for *years* with one that just got written.
regards, tom lane
В списке pgsql-hackers по дате отправления: