Re: Why does splitting $PGDATA and xlog yield a performance benefit?

On 26/08/15 05:54, David Kerr wrote:
> On Tue, Aug 25, 2015 at 10:16:37AM PDT, Andomar wrote:
>>> However, I know from experience that's not entirely true, (although it's not always easy to measure all aspects of your I/O bandwith).
>>>
>>> Am I missing something?
>>>
>> Two things I can think of:
>>
>> Transaction writes are entirely sequential. If you have disks
>> assigned for just this purpose, then the heads will always be in the
>> right spot, and the writes go through more quickly.
>>
>> A database server process waits until the transaction logs are
>> written and then returns control to the client. The data writes can
>> be done in the background while the client goes on to do other
>> things. Splitting up data and logs mean that there is less chance
>> the disk controller will cause data writes to interfere with log
>> files.
>>
>> Kind regards,
>> Andomar
>>
> hmm, yeah those are both what I'd lump into "I/O bandwith".
> If your disk subsystem is fast enough, or you're on a RAIDd SAN
> or EBS you'd either overcome that, or not neccssarily be able to.
>
>
>
Back when I actually understood the various timings of disc accessing on
a MainFrame system, back in the 1980's (disc layout & accessing, is way
more complicated now!), I found that there was a considerable difference
between mainly sequential & mostly random access - easily greater than a
factor of 5 (from memory) in terms of throughput.

Considering the time to move heads between tracks and rotational latency
(caused by not reading sequential blocks on the same track). There are
other complications, which I have glossed over!

Cheers,
Gavin