Re: There's random access and then there's random access

Поиск
Список
Период
Сортировка
От Gregory Stark
Тема Re: There's random access and then there's random access
Дата
Msg-id 87r6i26xpv.fsf@oxford.xeocode.com
обсуждение исходный текст
Ответ на Re: There's random access and then there's random access  (Mark Mielke <mark@mark.mielke.cc>)
Список pgsql-hackers
"Mark Mielke" <mark@mark.mielke.cc> writes:

> I didn't see exceeded 3X in the graph. But I certainly see 2X+ for most of the
> graphic, and ~3X for very small reads. Possibly, it is avoiding unnecessary
> read-ahead at the drive or OS levels?

Ahh! I think I see how you're misreading it now. You're comparing the pink
with the blue. That's not what's going on.

The X axis (which is logarithmic) is the degree of prefetch. So "1" means it's
prefetching one block then immediately reading it -- effectively not
prefetching at all. 10000 (actually the last data point is 8192) is completely
prefetching the whole data set.

The two data sets are the same tests run with ordered (ie, like a bitmap scan)
or unordered (ie, like a regular index scan) blocks. Unsurprisingly ordered
sets read faster with low levels of prefetch and both get faster the more
blocks you prefetch. What's surprising to me is that the advantage of the
ordered blocks doesn't diminish with prefetching.

--  Gregory Stark EnterpriseDB          http://www.enterprisedb.com Ask me about EnterpriseDB's On-Demand Production
Tuning


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

Предыдущее
От: Gregory Stark
Дата:
Сообщение: Re: There's random access and then there's random access
Следующее
От: Tom Lane
Дата:
Сообщение: Re: weird - invalid string enlargement request size