Re: few ideas for pgbench

From: Pavel Stehule <pavel(dot)stehule(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: few ideas for pgbench
Date: 2021-05-05 10:22:34
Message-ID: CAFj8pRAD9FNX_TMm7kf_O8RGJmbScrznkFo+JEEkn27P2gJ0qQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

st 5. 5. 2021 v 11:55 odesílatel Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> napsal:

>
> Hello Pavel,
>
> > This is not a simple question. Personally I prefer to show this info
> every
> > time, although it can be redundant. Just for check and for more simple
> > automatic processing.
> >
> > When I run pgbench, I usually work with more releases together, so the
> > server version is important info.
>
> Ok. Yes.
>
> >>> 2. can ve generate some output in structured format - XML, JSON ?
> >>
> >> It is obviously possible, but that would mean some code. ISTM that the
> >> various outputs are easy enough to parse and convert to anything without
> >> needing a special format? Is there some particular part you have in
> mind?
> >>
> >
> > I thought about something what I can simply import to Postgres or to R.
> > But maybe XML or JSON is a bad idea.
> >
> > What about CSV? Any run can produce one row.
>
> Yep, CSV is simple and nice. It depends on what information you would
> like. For instance for progress report (-P 1) or logs/sampling (-l) would
> be relevant candidates for CSV. Not so much for the final report, though.
>

I think so there can be almost all information. We have to ensure
consistency of columns.

The basic usage can be

for ....
do
pg_bench ... >> logfile
done

and log file can looks like

start time, rowno, serverver, clientver, connections, scale, readonly,
jobs, tps, latency, ...

The header row can be optional

>
> --
> Fabien.
>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2021-05-05 10:30:45 Re: Small issues with CREATE TABLE COMPRESSION
Previous Message Laurenz Albe 2021-05-05 10:03:08 Re: Update maintenance_work_mem/autovacuum_work_mem to reflect the 1GB limitation with VACUUM