Updated posix fadvise patch v19

From: Gregory Stark <stark(at)enterprisedb(dot)com>
To: Postgres <pgsql-hackers(at)postgresql(dot)org>
Subject: Updated posix fadvise patch v19
Date: 2008-10-30 20:02:50
Message-ID: 87ljw5c0lx.fsf@oxford.xeocode.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


Here is an updated posix_fadvise patch against CVS HEAD. It's my first patch
generated using git, yay. I remembered to strip out configure (WHY is that
STILL in CVS!?) and convert it to context diff, but if there's anything else
I've missed just shout.

Changes from before:

1) Based on discussions changed the parameter to effective_io_concurrency and
modified the documentation discussion to include comments about SSDs and
experimentation being necessary.

2) standardized all references to "prefetch" from the mixture of same and
"preread" and "advise". This means the main entry point is now
PrefetchBuffer().

3) Added run-time check for buggy glibc versions with bad posix_fadvise()
since it was pointed out that someone could run on a different version of
glibc than it was compiled on (such as with binary installers). I kept the
autoconf test though arguably it's redundant now and could be removed.

Also, the previous patch included support for Zoltan's situation using
POSIX_FADV_SEQUENTIAL for bulk sequential scans. I experimented with this and
was not able to find any situation it improved. I've left it in so others can
test and show it's helpful. This bit of code is a bit less polished -- it's
missing documentation for the guc variable and there are some #defines which
are probably in the wrong .h file (and probably should be an enum).

This code is entirely separate from the prefetching code. They happen to both
use posix_fadvise but I don't think they belong in the same abstraction for
Postgres. PrefetchBuffer does just one thing -- prefetches a buffer.
Sequential i/o needs to be set and tracked per-file.

I have not changed the query costing side of things. I'm a bit leery about
making those changes as I fear it will lead me to propose a major reworking of
these parameters and I don't want to go there...

Attachment Content-Type Size
posix-fadvise-v19.patch.gz application/octet-stream 14.8 KB

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Heikki Linnakangas 2008-10-30 20:05:34 Re: User defined I/O conversion casts
Previous Message Zdenek Kotala 2008-10-30 19:44:18 PG_PAGE_LAYOUT_VERSION 5 - time for change