Re: PATCH: pgbench - merging transaction logs - Mailing list pgsql-hackers

From didier
Subject Re: PATCH: pgbench - merging transaction logs
Date
Msg-id CAJRYxuL7nRA8PR41dk7dVyKqsRD+t=Moo5zGrrinf0Y9Lj+6FA@mail.gmail.com
Whole thread Raw
In response to Re: PATCH: pgbench - merging transaction logs  (Fabien COELHO <coelho@cri.ensmp.fr>)
Responses Re: PATCH: pgbench - merging transaction logs
List pgsql-hackers
Hi,

On Sat, Mar 21, 2015 at 10:37 AM, Fabien COELHO <coelho@cri.ensmp.fr> wrote:

>>   no logging: 18672 18792 18667 18518 18613 18547
>> with logging: 18170 18093 18162 18273 18307 18234
>>
>> So on average, that's 18634 vs. 18206, i.e. less than 2.5% difference.
>> And with more expensive transactions (larger scale, writes, ...) the
>> difference will be much smaller.
>
>
> Ok. Great!
>
> Let us take this as a worst-case figure and try some maths.
>
> If fprintf takes p = 0.025 (1/40) of the time, then with 2 threads the
> collision probability would be about 1/40 and the delayed thread would be
> waiting for half this time on average, so the performance impact due to
> fprintf locking would be negligeable (1/80 delay occured in 1/40 cases =>
> 1/3200 time added on the computed average, if I'm not mistaken).
If  threads run more or less the same code with the same timing after
a while they will lockstep  on synchronization primitives and your
collision probability will be very close to 1.

Moreover  they will write to the same cache lines for every fprintf
and this is very very bad even without atomic operations.

Regards
Didier



pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: assessing parallel-safety
Next
From: Tom Lane
Date:
Subject: Re: Using 128-bit integers for sum, avg and statistics aggregates