Re: There's random access and then there's random access - Mailing list pgsql-hackers

From Gregory Stark
Subject Re: There's random access and then there's random access
Date
Msg-id 87r6i26xpv.fsf@oxford.xeocode.com
Whole thread Raw
In response to Re: There's random access and then there's random access  (Mark Mielke <mark@mark.mielke.cc>)
List 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 by date:

Previous
From: Gregory Stark
Date:
Subject: Re: There's random access and then there's random access
Next
From: Tom Lane
Date:
Subject: Re: weird - invalid string enlargement request size