| From: | "tsunakawa(dot)takay(at)fujitsu(dot)com" <tsunakawa(dot)takay(at)fujitsu(dot)com> |
|---|---|
| To: | 'Alvaro Herrera' <alvherre(at)alvh(dot)no-ip(dot)org>, "iwata(dot)aya(at)fujitsu(dot)com" <iwata(dot)aya(at)fujitsu(dot)com>, Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> |
| Cc: | "k(dot)jamison(at)fujitsu(dot)com" <k(dot)jamison(at)fujitsu(dot)com>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | RE: libpq debug log |
| Date: | 2021-02-04 01:18:25 |
| Message-ID: | TYAPR01MB2990FA689A57272C96948207FEB39@TYAPR01MB2990.jpnprd01.prod.outlook.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
From: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
> I'm pretty sure I named the flag PQTRACE_SUPPRESS_TIMESTAMP (and I
> prefer SUPPRESS to NOOUTPUT), because the idea is that the timestamp is
> printed by default. I think that's the sensible decision: applications
> prefer to have timestamps, even if there's a tiny bit of overhead. We
> don't want to force them to pass a flag for that. We only want the
> no-timestamp behavior in order to be able to use it for libpq internal
> testing.
Agreed. It makes sense to print timestamps by default because this feature will be used to diagnose slowness outside the database server. (I misunderstood the motivation to introduce the flag).
Regards
Takayuki Tsunakawa
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Zhihong Yu | 2021-02-04 01:35:34 | Re: WIP: BRIN multi-range indexes |
| Previous Message | torikoshia | 2021-02-04 01:16:47 | Re: Is it useful to record whether plans are generic or custom? |