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 16:11:36 |
Message-ID: | 24627.1067875896@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Neil Conway <neilc(at)samurai(dot)com> writes:
> On Mon, 2003-11-03 at 10:01, Tom Lane wrote:
>> I would expect POSIX_FADV_SEQUENTIAL to reduce the chance that a page
>> will be kept in buffer cache after it's been used.
> I don't think that can be reasonably implied from the POSIX text, which
> is merely:
> POSIX_FADV_SEQUENTIAL
> Specifies that the application expects to access the specified
> data sequentially from lower offsets to higher offsets.
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.
A reasonable implementation of the POSIX semantics would need to balance
this consideration against the likelihood that some other process would
want to access some of these pages later. But I would certainly expect
it to reduce the probability of keeping the pages in cache.
> The present Linux implementation doesn't do this, AFAICS --
So it only does part of what it could do. No surprise...
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Carroll, Catherine A. | 2003-11-03 16:25:35 | Re: Annotated release notes |
Previous Message | Tom Lane | 2003-11-03 15:47:04 | Re: Experimental patch for inter-page delay in VACUUM |