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

From Magnus Hagander
Subject Re: [HACKERS] log_destination=file
Date
Msg-id CABUevExEBo0D7p5AFBYZAVzwUCC9Tm4M-wXrkjMa2sgHhOqM4A@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] log_destination=file  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [HACKERS] log_destination=file
List pgsql-hackers
On Thu, Sep 7, 2017 at 7:02 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Dmitry Dolgov <9erthalion6@gmail.com> writes:
>> On 31 August 2017 at 14:49, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> pgbench with log_statement = all would be a pretty easy test case.

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

Ouch.  That seems like rather a large hit :-(.  I actually expected
it to be close to negligible, but I don't think 20% qualifies.

Agreed, that's a lot more than I expected. A few questions though:

1. where was stderr actually sent? To the console, to /dev/null or to a file?

2. Could you run the same thing (on the same machine) with the logging collector on and logging to file, without the patch? I'd assume that gives performance similar to running with the patch, but it would be good to confirm that.

And thanks for running the benchmark, saved me some time!


--

pgsql-hackers by date:

Previous
From: Thomas Munro
Date:
Subject: Re: [HACKERS] Moving relation extension locks out of heavyweight lock manager
Next
From: Tom Lane
Date:
Subject: Re: [HACKERS] [PROPOSAL] Use SnapshotAny in get_actual_variable_range