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.
>
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 |