> On 7 September 2017 at 15:46, Dmitry Dolgov <9erthali...@gmail.com> wrote:
>
> 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
> On 8 September 2017 at 01:32, Magnus Hagander wrote:
>
> 1. where was stderr actually sent? To the console, to /dev/null or to a
file?
To the console (but I can also try other options, although I'm not sure if
it would have any impact).
> 2. Could you run the same thing (on the same machine) w
On Thu, Sep 7, 2017 at 7:02 AM, Tom Lane wrote:
> Dmitry Dolgov <9erthali...@gmail.com> writes:
> >> On 31 August 2017 at 14:49, Tom Lane 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.
>
Dmitry Dolgov <9erthali...@gmail.com> writes:
>> On 31 August 2017 at 14:49, Tom Lane 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 e
Hi
> On 31 August 2017 at 14:49, Tom Lane 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
>> wri
On Fri, Sep 1, 2017 at 6:44 PM, Tom Lane wrote:
> Magnus Hagander writes:
> > On Fri, Sep 1, 2017 at 6:00 PM, Greg Stark wrote:
> >> So what happens now with these messages? My understanding is that
> >> they're missing from the CSV logs and are simply inserted into the
> >> text logs without a
Magnus Hagander writes:
> On Fri, Sep 1, 2017 at 6:00 PM, Greg Stark wrote:
>> So what happens now with these messages? My understanding is that
>> they're missing from the CSV logs and are simply inserted into the
>> text logs without any log_line_prefix? The logging collector doesn't
>> recogni
On Fri, Sep 1, 2017 at 6:00 PM, Greg Stark wrote:
> On 31 August 2017 at 13:49, Tom Lane wrote:
> > Magnus Hagander writes:
> >> On Thu, Aug 31, 2017 at 2:34 PM, Tom Lane wrote:
> > Yes, it's pretty important, because of assorted stuff not-under-our-
> > control that doesn't know about ereport
On 31 August 2017 at 13:49, Tom Lane wrote:
> Magnus Hagander writes:
>> On Thu, Aug 31, 2017 at 2:34 PM, Tom Lane wrote:
> Yes, it's pretty important, because of assorted stuff not-under-our-
> control that doesn't know about ereport and will just print to stderr
> anyway. Some examples: dynam
Magnus Hagander writes:
> On Thu, Aug 31, 2017 at 2:34 PM, Tom Lane wrote:
>> Right, because the decision whether to redirect stdout/stderr can't
>> be changed on the fly.
> Right.
> We could of course also say we only care about things generated by our
> ereport framework, in which case we don
On Thu, Aug 31, 2017 at 2:34 PM, Tom Lane wrote:
> Magnus Hagander writes:
> > My understanding is that the main reason for this is that we cannot
> change
> > logging_collector without restarting postmaster, whereas we can change
> > log_destination.
>
> Right, because the decision whether to r
Magnus Hagander writes:
> My understanding is that the main reason for this is that we cannot change
> logging_collector without restarting postmaster, whereas we can change
> log_destination.
Right, because the decision whether to redirect stdout/stderr can't
be changed on the fly.
> My suggest
Attached is a very much VIP (AKA rough draft) for $subject.
Right now we have two parameters controlling logging destination, and they
work in interesting combinations:
log_destination=stderr, logging_collector=off -> log to stderr (makes sense)
log_destination=stderr, logging_collector=on -> lo
13 matches
Mail list logo
