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

From: Gregory Stark <stark(at)enterprisedb(dot)com>
To: "Mark Mielke" <mark(at)mark(dot)mielke(dot)cc>
Cc: "pgsql-hackers list" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: There's random access and then there's random access
Date: 2007-12-04 19:55:56
Message-ID: 87r6i26xpv.fsf@oxford.xeocode.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"Mark Mielke" <mark(at)mark(dot)mielke(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2007-12-04 21:19:47 Re: weird - invalid string enlargement request size
Previous Message Gregory Stark 2007-12-04 19:42:57 Re: There's random access and then there's random access