From: | Stefan Kaltenbrunner <stefan(at)kaltenbrunner(dot)cc> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Proposal for 9.1: WAL streaming from WAL buffers |
Date: | 2010-06-11 15:15:24 |
Message-ID: | 4C12530C.6010006@kaltenbrunner.cc |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 06/11/2010 04:47 PM, Tom Lane wrote:
> Stefan Kaltenbrunner<stefan(at)kaltenbrunner(dot)cc> writes:
>> hmm not sure that is what fujii tried to say - I think his point was
>> that in the original case we would have serialized all the operations
>> (first write+sync on the master, network afterwards and write+sync on
>> the slave) and now we could try parallelizing by sending the wal before
>> we have synced locally.
>
> Well, we're already not waiting for fsync, which is the slowest part.
> If there's a performance problem, it may be because FADVISE_DONTNEED
> disables kernel buffering so that we're forced to actually read the data
> back from disk before sending it on down the wire.
hmm ok - but assuming sync rep we would end up with something like the
following(hypotetically assuming each operation takes 1 time unit):
originally:
write 1
sync 1
network 1
write 1
sync 1
total: 5
whereas in the new case we would basically have the write+sync compete
with network+write+sync in parallel(total 3 units) and we would only
have to wait for the slower of those two sets of operations instead of
the total time of both or am I missing something.
Stefan
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2010-06-11 15:23:10 | Re: LLVM / clang |
Previous Message | Tom Lane | 2010-06-11 14:59:43 | Re: hstore ==> and deprecate => |