Re: PATCH: pgbench - merging transaction logs

Поиск
Список
Период
Сортировка
От didier
Тема Re: PATCH: pgbench - merging transaction logs
Дата
Msg-id CAJRYxuL7nRA8PR41dk7dVyKqsRD+t=Moo5zGrrinf0Y9Lj+6FA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: PATCH: pgbench - merging transaction logs  (Fabien COELHO <coelho@cri.ensmp.fr>)
Ответы Re: PATCH: pgbench - merging transaction logs  (Fabien COELHO <coelho@cri.ensmp.fr>)
Список 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 по дате отправления:

Предыдущее
От: Amit Kapila
Дата:
Сообщение: Re: assessing parallel-safety
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Using 128-bit integers for sum, avg and statistics aggregates