On Tue, Feb 19, 2013 at 5:48 PM, Simon Riggs <si...@2ndquadrant.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
