Re: posix_fadvise missing in the walsender

On Tue, Feb 19, 2013 at 5:48 PM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
> I agree with Merlin and Joachim - if we have the call in one place, we
> should have it in both.

We might want to assess whether we even want to have it one place.
I've seen cases where the existing call hurts performance, because of
WAL file recycling. If we don't flush the WAL file blocks out of
cache, then they're still there when we recycle the WAL file and we
can overwrite them without further I/O. But if we tell the OS to blow
them away, then it has to reread them when we try to overwrite the old
files, and so we stall waiting for the I/O. I was able to clearly
measure this problem back when I was hacking on write scalability, so
it's not a purely hypothetical risk.

As for the proposed optimization, I tend to doubt that it's a good
idea. We're talking about doing extra work to give the OS cache a
hint that may not be right anyway. Color me skeptical... but like
Heikki, I'm certainly willing to be proven wrong by some actual
benchmark results.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company