* Jeff Janes:
> Does the kernel really read a data block from disk into memory in
> order to immediately overwrite it? I would have thought it would
> optimize that away, at least if the writes are sized and aligned to
> 512 or 1024 bytes blocks (which WAL should be).
With Linux, you'd have to u
On Thu, Feb 21, 2013 at 12:16 PM, Jeff Janes wrote:
> Does the kernel really read a data block from disk into memory in
> order to immediately overwrite it? I would have thought it would
> optimize that away, at least if the writes are sized and aligned to
> 512 or 1024 bytes blocks (which WAL sh
On Wed, Feb 20, 2013 at 7:54 AM, Robert Haas wrote:
> On Tue, Feb 19, 2013 at 5:48 PM, Simon Riggs 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 w
On Wed, Feb 20, 2013 at 9:49 PM, Joachim Wieland wrote:
> So given the above, I think it's possible to come up with benchmarks
> that prove whatever you want to prove :-)
Yeah. :-(
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-h
On Wed, Feb 20, 2013 at 4:54 PM, Robert Haas wrote:
> On Tue, Feb 19, 2013 at 5:48 PM, Simon Riggs 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 w
On Tue, Feb 19, 2013 at 5:48 PM, Simon Riggs 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
On Tue, Feb 19, 2013 at 5:48 PM, Simon Riggs 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);
>
> I agree with Merlin and Joachim - if we have t
On 19 February 2013 20:19, Merlin Moncure 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);
>>>
> If that's the case, why have the advisory call at all?
On Mon, Feb 18, 2013 at 2:16 AM, Heikki Linnakangas
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);
>>
>> b
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 reason
10 matches
Mail list logo
