Skip site navigation (1) Skip section navigation (2)

Re: Initial prefetch performance testing

From: Gregory Stark <stark(at)enterprisedb(dot)com>
To: Greg Smith <gsmith(at)gregsmith(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Initial prefetch performance testing
Date: 2008-09-23 14:38:40
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Greg Smith <gsmith(at)gregsmith(dot)com> writes:

>> I have an updated patch I'll be sending along shortly. You might want to test
>> with that?
> Obviously I've got everything setup to test right now, am currently analyzing
> your earlier patch and the sequential scan fork that derived from it.  If
> you've got a later version of the bitmap heap scan one as well, I'll replace
> the one I had been planning to test (your bitmap-preread-v9) with that one when
> it's available.

Well here you go. It includes:

. Bitmap heap scans (as before)
. Index scans
. Setting POSIX_FADV_SEQUENTIAL for bulk sequential scans
. Improved (ie, debugged) autoconf tests for posix_fadvise 
  (and posix_fallocate though I don't have any code using it yet)

The bitmap heap scans are still prefetching the number of buffers I estimate
based on effective_spindle_count according to my magic formula. We've been
discussing throwing that out, I just haven't modified this to do that yet.

Index scans prefetch all pages for matching index tuples on the leaf page when
we do page-at-a-time scans. I haven't bothered doing the gradual ramp-up or
keeping a ring of the optimal size prefetched.

The sequential scan stuff is based on Zoltan's posts but done in a different
way. It passes an i/o access strategy to smgr and fd.c which keeps track of
what the previous strategy was and calls posix_fadvise if it's changed. This
will correctly handle queries which reference the same table twice even if one
reference is a sequential scan and the other is an index lookup.

I have *not* been able to observe any significant effect from
POSIX_FADV_SEQUENTIAL but I'm not sure what circumstances it was a problem. It
sounds like it's a peculiar situation which is not easy to reliably reproduce.

Attachment: bitmap-preread-v18.diff.gz
Description: application/octet-stream (13.6 KB)

In response to


pgsql-hackers by date

Next:From: Zdenek KotalaDate: 2008-09-23 15:12:52
Subject: Re: WIP patch: Collation support
Previous:From: Tom LaneDate: 2008-09-23 14:07:16
Subject: Re: Proposal: move column defaults into pg_attribute along with attacl

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group