From: | Neil Conway <neilc(at)samurai(dot)com> |
---|---|
To: | Pierre-Frédéric Caillaud <lists(at)boutiquenumerique(dot)com> |
Cc: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Anything to be gained from a 'Postgres Filesystem'? |
Date: | 2004-11-05 04:33:32 |
Message-ID: | 1099629212.10449.45.camel@localhost.localdomain |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On Thu, 2004-11-04 at 23:29, Pierre-Frédéric Caillaud wrote:
> There is also the fact that syncing after every transaction could be
> changed to syncing every N transactions (N fixed or depending on the data
> size written by the transactions) which would be more efficient than the
> current behaviour with a sleep.
Uh, which "sleep" are you referring to?
Also, how would interacting with the filesystem's journal effect how
often we need to force-write the WAL to disk? (ISTM we need to sync
_something_ to disk when a transaction commits in order to maintain the
WAL invariant.)
> There's fadvise to tell the OS to readahead on a seq scan (I think the OS
> detects it anyway)
Not perfectly, though; also, Linux will do a more aggressive readahead
if you tell it to do so via posix_fadvise().
> if there was a system call telling the OS "in the
> next seconds I'm going to read these chunks of data from this file (gives
> a list of offsets and lengths), could you put them in your cache in the
> most efficient order without seeking too much, so that when I read() them
> in random order, they will be in the cache already ?".
http://www.opengroup.org/onlinepubs/009695399/functions/posix_fadvise.html
POSIX_FADV_WILLNEED
Specifies that the application expects to access the specified
data in the near future.
-Neil
From | Date | Subject | |
---|---|---|---|
Next Message | Neil Conway | 2004-11-05 04:35:08 | Re: Anything to be gained from a 'Postgres Filesystem'? |
Previous Message | Neil Conway | 2004-11-05 04:28:39 | Re: Anything to be gained from a 'Postgres Filesystem'? |