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

Re: adding support for posix_fadvise()

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Neil Conway <neilc(at)samurai(dot)com>
Cc: Hannu Krosing <hannu(at)tm(dot)ee>,PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: adding support for posix_fadvise()
Date: 2003-11-03 23:38:01
Message-ID: 13156.1067902681@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Neil Conway <neilc(at)samurai(dot)com> writes:
> On Mon, 2003-11-03 at 11:11, Tom Lane wrote:
>> Why not?  The advice says that you're going to access the data
>> sequentially in the forward direction.  If you're not going to back up,
>> there is no point in keeping pages in cache after they've been read.

> The advice says: "I'm going to read this data sequentially, going
> forward." It doesn't say: "I'm only going to read the data once, and
> then not access it again" (ISTM that's what FADV_NOREUSE is for).

I'd believe that interpretation if the spec specifically allowed for
applying multiple "advice" values to the same fd.  However, given the
way the API is written, it sure looks like the intention is that only
the most recent advice value is valid for any one (portion of a) file.
If the intention was that you could specify both FADV_SEQUENTIAL and
FADV_NOREUSE, the usual Unix-y way to handle it would have been to
define these constants as bit mask values and specify that the parameter
to the syscall is a bitwise OR of multiple flags.  The way you are
interpreting it, there is no way to cancel an FADV_NOREUSE setting,
since there is no value that is the opposite setting.

			regards, tom lane

In response to

pgsql-hackers by date

Next:From: Marc G. FournierDate: 2003-11-04 00:51:51
Subject: Re: 7.4RC1 tag'd, branched and bundled ...
Previous:From: Tom LaneDate: 2003-11-03 23:19:29
Subject: Re: equal() perf tweak

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