Re: Anything to be gained from a 'Postgres Filesystem'?
От | Neil Conway |
---|---|
Тема | Re: Anything to be gained from a 'Postgres Filesystem'? |
Дата | |
Msg-id | 1099629212.10449.45.camel@localhost.localdomain обсуждение исходный текст |
Ответ на | Re: Anything to be gained from a 'Postgres Filesystem'? (Pierre-Frédéric Caillaud<lists@boutiquenumerique.com>) |
Список | 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
В списке pgsql-performance по дате отправления: