Re: [HACKERS] log_destination=file

Поиск
Список
Период
Сортировка
От Magnus Hagander
Тема Re: [HACKERS] log_destination=file
Дата
Msg-id CABUevExEBo0D7p5AFBYZAVzwUCC9Tm4M-wXrkjMa2sgHhOqM4A@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] log_destination=file  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: [HACKERS] log_destination=file  (Dmitry Dolgov <9erthalion6@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Thomas Munro
Дата:
Сообщение: Re: [HACKERS] Moving relation extension locks out of heavyweight lock manager
Следующее
От: Tom Lane
Дата:
Сообщение: Re: [HACKERS] [PROPOSAL] Use SnapshotAny in get_actual_variable_range