Postgres Pro
Downloads
Home   >   mailing lists

Re: [HACKERS] log_destination=file - Mailing list pgsql-hackers

From Dmitry Dolgov
Subject Re: [HACKERS] log_destination=file
Date
Msg-id CA+q6zcXS0xS53DUn3Zteg5jwKDGVTaSVaAZja+iAGTXrnrM14g@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] log_destination=file  (Magnus Hagander <magnus@hagander.net>)
Responses Re: [HACKERS] log_destination=file
List pgsql-hackers
Tree view
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 by date:

Previous
From: Alexey Chernyshov
Date:
Subject: Re: [HACKERS] index-only count(*) for indexes supporting bitmap scans
Next
From: Michael Banck
Date:
Subject: Re: [HACKERS] Create replication slot in pg_basebackup if requestedand not yet present