Re: Allowing WAL fsync to be done via O_SYNC
От | Alfred Perlstein |
---|---|
Тема | Re: Allowing WAL fsync to be done via O_SYNC |
Дата | |
Msg-id | 20010315114013.A29888@fw.wintelcom.net обсуждение исходный текст |
Ответ на | Re: Allowing WAL fsync to be done via O_SYNC (Peter Eisentraut <peter_e@gmx.net>) |
Ответы |
Re: Allowing WAL fsync to be done via O_SYNC
|
Список | pgsql-hackers |
* Peter Eisentraut <peter_e@gmx.net> [010315 11:33] wrote: > Alfred Perlstein writes: > > > Sorry, what's a GUC? :) > > Grand Unified Configuration system > > It's basically a cute name for the achievement that there's now a single > name space and interface for (almost) all postmaster run time > configuration variables, Oh, thanks. Well considering that, a runtime check for doing_sync_wal_writes == 1 shouldn't be that expensive. Sort of the inverse of -F, meaning that we're using O_SYNC for WAL writes, we don't need to fsync it. Btw, if you guys want to get some speed with WAL, I'd implement a write-behind process if it was possible to do the O_SYNC writes. ... And since we're sorta on the topic of IO, I noticed that it looks like (at least in 7.0.3) that vacuum and certain other routines read files in reverse order. The problem (at least in FreeBSD) is that we haven't tuned the system to detect reverse reading and hence don't do much readahead. There may be some going on as a function of the read clustering, but I'm not entirely sure. I'd suspect that other OSs might have neglected to check for reverse reading of files as well, but I'm not sure. Basically, if there was a way to do this another way, or anticipate the backwards motion and do large reads, it may add latency, but it should improve performance. -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org]
В списке pgsql-hackers по дате отправления: