Re: pgbench -i progress output on terminal

From: Amit Langote <amitlangote09(at)gmail(dot)com>
To: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: pgbench -i progress output on terminal
Date: 2019-11-29 17:26:18
Message-ID: CA+HiwqHgSs7-8Q-uz6Yrqxbd0TSfw-MP95deh+fSJ80ZP6C83g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi Fabien,

On Fri, Nov 29, 2019 at 10:13 PM Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> wrote:
> > I wonder why we don't use the same style for $subject as pg_basebackup
> > --progress, that is, use a carriage return instead of a newline after
> > each line reporting the number of tuples copied?
>
> Patch applies cleanly, compiles, and works for me.

Thanks a lot for the quick review.

> My 0.02€:
>
> fprintf -> fputs or fputc to avoid a format parsing, or maybe use %c in
> the formats.
>
> As the format is not constant, ISTM that vfprintf should be called, not
> fprintf (even if in practice fprintf does call vfprintf internally).
>
> I'm not sure what the compilers does with isatty(fileno(stderr)), maybe
> the eol could be precomputed:
>
> char eol = isatty(...) ? '\r' : '\n';
>
> and reused afterwards in the loop:
>
> fprintf(stderr, ".... %c", ..., eol);
>
> that would remove the added in-loop printing.

I have updated the patch based on these observations. Attached v2.

Thanks,
Amit

Attachment Content-Type Size
compactify-pgbench-init-progress-output_v2.patch application/octet-stream 2.1 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Masahiko Sawada 2019-11-29 17:44:58 Using XLogFileNameP in critical section
Previous Message Tom Lane 2019-11-29 15:30:47 Re: Update minimum SSL version