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
|
Список | 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 по дате отправления: