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.
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 |