Re: [Testperf-general] Re: ExclusiveLock - Mailing list pgsql-hackers

From Greg Stark
Subject Re: [Testperf-general] Re: ExclusiveLock
Date
Msg-id 87r7mlxxoj.fsf@stark.xeocode.com
Whole thread Raw
In response to Re: [Testperf-general] Re: ExclusiveLock  (Simon Riggs <simon@2ndquadrant.com>)
Responses Re: [Testperf-general] Re: ExclusiveLock  (Simon Riggs <simon@2ndquadrant.com>)
Re: [Testperf-general] Re: ExclusiveLock  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Simon Riggs <simon@2ndquadrant.com> writes:

> - Find a way to reduce rotational delay when repeatedly writing last WAL
> page 
> 
> Currently fsync of WAL requires the disk platter to perform a full
> rotation to fsync again. One idea is to write the WAL to different
> offsets that might reduce the rotational delay. 

Once upon a time when you formatted hard drives you actually gave them an
interleave factor for a similar reason. These days you invariably use an
interleave of 1, ie, store the blocks continuously. Whether that's because
controllers have become fast enough to keep up with the burst rate or because
the firmware is smart enough to handle the block interleaving invisibly isn't
clear to me.

I wonder if formatting the drive to have an interleave >1 would actually
improve performance of the WAL log. 

It would depend a lot on the usage pattern though. A heavily used system might
be able to generate enough WAL traffic to keep up with the burst rate of the
drive. And an less used system might benefit but might lose.

Probably now the less than saturated system gets close to the average
half-rotation-time latency. This idea would only really help if you have a
system that happens to be triggering pessimal results worse than that due to
unfortunate timing.

-- 
greg



pgsql-hackers by date:

Previous
From: Neil Conway
Date:
Subject: Re: patch: plpgsql - access records with rec.(expr)
Next
From: Simon Riggs
Date:
Subject: Re: [Testperf-general] Re: ExclusiveLock