Re: pgbench - use pg logging capabilities

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: pgbench - use pg logging capabilities
Date: 2020-01-10 08:27:51
Message-ID: 20200110082751.GB250447@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Jan 10, 2020 at 08:52:17AM +0100, Fabien COELHO wrote:
> Compared to dealing with the level inside the call, the use of the level
> variable avoids a call-test-return cycle in this case, and the unlikely
> should help the compiler reorder instructions so that no actual branch is
> taken under the common case.
>
> So I think that the current situation is a good thing at least for debug.

If you look at some of my messages on other threads, you would likely
notice that my mood of the day is to not design things which try to
outsmart a user's expectations :)

So I would stand on the position to just remove those likely/unlikely
parts if we want this logging to be generic.

> For other levels, they are on by default AND would not be placed at critical
> performance points, so the whole effort of avoiding the call are moot.
>
> I agree with Tom that __pg_log_level variable name violates usages.

My own taste would be to still keep the variable local to logging.c,
and use a "get"-like routine to be consistent with the "set" part. I
don't have to be right, let's see where this discussion leads us.

(I mentioned that upthread, but I don't think it is a good idea to
discuss about a redesign of those routines on a thread about pgbench
based on $subject. All the main players are here so it likely does
not matter, but..)
--
Michael

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Konstantin Knizhnik 2020-01-10 08:47:42 Re: [Proposal] Global temporary tables
Previous Message Michael Paquier 2020-01-10 08:01:25 Re: Assert failure due to "drop schema pg_temp_3 cascade" for temporary tables and \d+ is not showing any info after drooping temp table schema