Re: [HACKERS] log_destination=file

Поиск
Список
Период
Сортировка
От Dmitry Dolgov
Тема Re: [HACKERS] log_destination=file
Дата
Msg-id CA+q6zcXS0xS53DUn3Zteg5jwKDGVTaSVaAZja+iAGTXrnrM14g@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] log_destination=file  (Magnus Hagander <magnus@hagander.net>)
Ответы Re: [HACKERS] log_destination=file  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
Дерево обсуждения
Hi

> On 31 August 2017 at 14:49, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Are you actually asking for a benchmark of if logging gets slower?
>
> Yes.
>
>> If so,
>> could you suggest a workload to make an actual benchmark of it (where
>> logging would be high enough that it could be come a bottleneck -- and not
>> writing the log data to disk, but the actual logging). I'm not sure what a
>> good one would be.
>
> pgbench with log_statement = all would be a pretty easy test case.

This part of the discussion caught my attention, and I tried to perform such
easy test. I was doing:

pgbench -S -j2 -c${clients} -T500 test

with `log_statement=all` and `log_destination=stderr`, what I assume should be
enough to get some approximation for numbers.

scaling factor: 100
average latency:

clients     patch       master

10          1.827       1.456

20          4.027       3.300

30          6.284       4.921

40          8.409       6.767

50          10.985     8.646

It seems that for this particular workload it was about 20-25% slower.

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Alexey Chernyshov
Дата:
Сообщение: Re: [HACKERS] index-only count(*) for indexes supporting bitmap scans
Следующее
От: Michael Banck
Дата:
Сообщение: Re: [HACKERS] Create replication slot in pg_basebackup if requestedand not yet present