Re: posix_fadvise missing in the walsender
От | Merlin Moncure |
---|---|
Тема | Re: posix_fadvise missing in the walsender |
Дата | |
Msg-id | CAHyXU0xRQLWdsAme=uAHs6gT3GfWn-=qY5MZGzkSXx6caeRngQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: posix_fadvise missing in the walsender (Heikki Linnakangas <hlinnakangas@vmware.com>) |
Ответы |
Re: posix_fadvise missing in the walsender
|
Список | pgsql-hackers |
On Mon, Feb 18, 2013 at 2:16 AM, Heikki Linnakangas <hlinnakangas@vmware.com> wrote: > On 17.02.2013 14:55, Joachim Wieland wrote: >> >> In access/transam/xlog.c we give the OS buffer caching a hint that we >> won't need a WAL file any time soon with >> >> posix_fadvise(openLogFile, 0, 0, POSIX_FADV_DONTNEED); >> >> before closing the WAL file, but only if we don't have walsenders. >> That's reasonable because the walsender will reopen that same file >> shortly after. >> >> However the walsender doesn't call posix_fadvise once it's done with >> the file and I'm proposing to add this to walsender.c for consistency >> as well. >> >> Since there could be multiple walsenders, only the "slowest" one >> should call this function. Finding out the slowest walsender can be >> done by inspecting the shared memory and looking at the sentPtr of >> each walsender. > > > I doubt it's worth it, the OS cache generally does a reasonable job at > deciding what to keep. In the non-walsender case, it's pretty clear that we > don't need the WAL file anymore, but if we need to work any harder than a > one-line posix_fadvise call, meh. If that's the case, why have the advisory call at all? The OS is being lied too (in some cases)... merlin
В списке pgsql-hackers по дате отправления: