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 withposix_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. I could be convinced otherwise with some performance test results, of course.
- Heikki -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
