From: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
---|---|
To: | Mark Wong <markwkm(at)gmail(dot)com> |
Cc: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: fix use of posix_fadvise in xlog.c |
Date: | 2010-06-10 15:37:49 |
Message-ID: | 4C1106CD.6030205@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 10/06/10 18:17, Mark Wong wrote:
> On Jun 9, 2010, at 11:25 PM, Heikki Linnakangas
> <heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:
>> I don't think POSIX_FADV_DONTNEED does what you think it does. It
>> tells the kernel that "you don't need to keep these pages in the cache
>> anymore, I won't be accessing them anymore". If you call it when you
>> open the file, before reading/writing, there is nothing in the cache
>> and the call will do nothing.
>
> Oops, my bad. I think I was confused by the short description in the man
> page. I didn't read the longer descriptoon. :( Then would it be worth
> making the this call after the file is zeroed out?
Not sure. If you're churning through WAL files at a reasonable speed,
the zeroed-out file will soon be written to again. OTOH, we always write
whole pages, so maybe the OS is smart enough to not read the page back
to memory just to overwrite it.
In a steady-state situation new WAL files are not created very often
because we recycle old ones, so it probably doesn't make much difference.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Max Williams | 2010-06-10 15:40:06 | Re: Large (almost 50%!) performance drop after upgrading to 8.4.4? |
Previous Message | Andrew Dunstan | 2010-06-10 15:33:25 | Re: Command to prune archive at restartpoints |