Re: log_destination=file

From: Dmitry Dolgov <9erthalion6(at)gmail(dot)com>
To: Magnus Hagander <magnus(at)hagander(dot)net>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Greg Stark <stark(at)mit(dot)edu>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: log_destination=file
Date: 2017-09-07 13:46:17
Message-ID: CA+q6zcXS0xS53DUn3Zteg5jwKDGVTaSVaAZja+iAGTXrnrM14g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi

> On 31 August 2017 at 14:49, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Banck 2017-09-07 13:54:48 Re: Create replication slot in pg_basebackup if requested and not yet present
Previous Message Alexey Chernyshov 2017-09-07 13:18:37 Re: index-only count(*) for indexes supporting bitmap scans