Re: So, is COUNT(*) fast now?

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: So, is COUNT(*) fast now?
Дата
Msg-id 201110221754.15396.andres@anarazel.de
обсуждение исходный текст
Ответ на Re: So, is COUNT(*) fast now?  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: So, is COUNT(*) fast now?
Список pgsql-hackers
On Saturday, October 22, 2011 05:20:26 PM Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
> > On Friday, October 21, 2011 08:14:12 PM Robert Haas wrote:
> >> On Fri, Oct 21, 2011 at 2:08 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> >>> It's not "touching six times less data".  It's touching the exact same
> >>> number of tuples either way, just index tuples in one case and heap
> >>> tuples in the other.
> >> 
> >> Yeah, but it works out to fewer pages.
> > 
> > But access to those is not sequential. I guess if you measure cache hit
> > ratios the index scan will come out significantly worse.
> 
> Huh?  In the case he's complaining about, the index is all in RAM.
> Sequentiality of access is not an issue (at least not at the page
> level --- within a page I suppose there could be cache-line effects).
I was talking about L2/L3 caches...

Andres


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

Предыдущее
От: "Joshua D. Drake"
Дата:
Сообщение: Re: database file encryption.
Следующее
От: Tom Lane
Дата:
Сообщение: Re: So, is COUNT(*) fast now?