From: | Neil Conway <neilc(at)samurai(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
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:59:24 |
Message-ID: | 1067878764.3089.369.camel@tokyo |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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). For
example, the following is a perfectly reasonable sequential access
pattern:
a,b,c,a,b,c,a,b,c,a,b,c
(i.e. repeatedly scanning through a large file, say for a data-analysis
app that does multiple passes over the input data). It might not be a
particularly common database reference pattern, but just because an app
is doing a sequential read says little about the temporal locality of
references to the pages in question.
-Neil
From | Date | Subject | |
---|---|---|---|
Next Message | Hannu Krosing | 2003-11-03 17:17:40 | Re: adding support for posix_fadvise() |
Previous Message | Neil Conway | 2003-11-03 16:47:55 | Re: equal() perf tweak |