Re: Allowing WAL fsync to be done via O_SYNC
От | Alfred Perlstein |
---|---|
Тема | Re: Allowing WAL fsync to be done via O_SYNC |
Дата | |
Msg-id | 20010315115121.B29888@fw.wintelcom.net обсуждение исходный текст |
Ответ на | Re: Allowing WAL fsync to be done via O_SYNC (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
* Tom Lane <tgl@sss.pgh.pa.us> [010315 11:45] wrote: > Alfred Perlstein <bright@wintelcom.net> 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. > > Vacuum does that because it's trying to push tuples down from the end > into free space in earlier blocks. I don't see much way around that > (nor any good reason to think that it's a critical part of vacuum's > performance anyway). Where else have you seen such behavior? Just vacuum, but the source is large, and I'm sort of lacking on database-foo so I guessed that it may be done elsewhere. You can optimize this out by implementing the read behind yourselves sorta like this: struct sglist * read(fd, len) { if (fd.lastpos - fd.curpos <= THRESHOLD) { fd.curpos = fd.lastpos - THRESHOLD; len = THRESHOLD;} return (do_read(fd, len)); } of course this is entirely wrong, but illustrates what would/could help. I would fix FreeBSD, but it's sort of a mess and beyond what I've got time to do ATM. -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org]
В списке pgsql-hackers по дате отправления: