Re: posix_fadvise() and pg_receivexlog
От | Fujii Masao |
---|---|
Тема | Re: posix_fadvise() and pg_receivexlog |
Дата | |
Msg-id | CAHGQGwEBO0F1LnMLyv5exap508cKwk6hBU-g8X2YmOKPaNUNMA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: posix_fadvise() and pg_receivexlog (Heikki Linnakangas <hlinnakangas@vmware.com>) |
Ответы |
Re: posix_fadvise() and pg_receivexlog
|
Список | pgsql-hackers |
On Thu, Aug 7, 2014 at 3:59 AM, Heikki Linnakangas <hlinnakangas@vmware.com> wrote: > On 08/06/2014 08:39 PM, Fujii Masao wrote: >> >> Hi, >> >> The WAL files that pg_receivexlog writes will not be re-read soon >> basically, >> so we can advise the OS to release any cached pages when WAL file is >> closed. I feel inclined to change pg_receivexlog that way. Thought? > > > -1. The OS should be smart enough to not thrash the cache by files that are > written sequentially and never read. Yep, the OS should be so smart, but I'm not sure if it actually is. Maybe not, so I was thinking that posix_fadvise is called when the server closes WAL file. > If we go down this path, we'd need to > sprinkle posix_fadvises into many, many places. Yes, that's valid concern. But if we can prove that adding posix_fadvise to a certain place can improve the performance well, I'm inclined to do that. > Anyway, who are we to say that they won't be re-read soon? You might e.g > have a secondary backup site where you copy the files received by > pg_receivexlog, as soon as they're completed. So whether posix_fadvise is called or not needs to be exposed as an user-configurable option. We would need to measure how useful exposing that is, though. Regards, -- Fujii Masao
В списке pgsql-hackers по дате отправления: