Re: PATCH: pgbench - merging transaction logs

From: didier <did447(at)gmail(dot)com>
To: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
Cc: Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL Developers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: PATCH: pgbench - merging transaction logs
Date: 2015-03-21 14:58:39
Message-ID: CAJRYxuL7nRA8PR41dk7dVyKqsRD+t=Moo5zGrrinf0Y9Lj+6FA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On Sat, Mar 21, 2015 at 10:37 AM, Fabien COELHO <coelho(at)cri(dot)ensmp(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2015-03-21 15:32:58 Re: Using 128-bit integers for sum, avg and statistics aggregates
Previous Message Amit Kapila 2015-03-21 14:28:37 Re: assessing parallel-safety