Re: [HACKERS] log_destination=file
| От | Dmitry Dolgov |
|---|---|
| Тема | Re: [HACKERS] log_destination=file |
| Дата | |
| Msg-id | CA+q6zcWrX7Yo6FsdGHv6FR0EYjK8_vx=EQKUGJ8_DfjynmHRDg@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: [HACKERS] log_destination=file (Dmitry Dolgov <9erthalion6@gmail.com>) |
| Ответы |
Re: [HACKERS] log_destination=file
|
| Список | pgsql-hackers |
> On 7 September 2017 at 15:46, Dmitry Dolgov <9erthalion6@gmail.com> wrote:
>
> It seems that for this particular workload it was about 20-25% slower.
>
> It seems that for this particular workload it was about 20-25% slower.
Hmm...looks like I provided misleading data, sorry. The numbers from previous
email are correct and I'm able to reproduce them, but surprisingly for me only
for one particular situation when `log_statement=all; log_destination=stderr`
and stderr is sent to a console with a tmux session running in it (and apparently
it has some impact on the performance, but I'm not sure how exactly). In all
other cases (when stderr is sent to a plain console, /dev/null, or we send logs
to a file) numbers are different, and the difference between patch and master
is quite less significant.
average latency:
clients patch master
10 0.321 0.286
20 0.669 0.602
30 1.016 0.942
40 1.358 1.280
50 1.727 1.637
В списке pgsql-hackers по дате отправления: