Re: [HACKERS] pgbench - allow to store select results into variables

From: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
To: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Michael Paquier <michael(at)paquier(dot)xyz>, Stephen Frost <sfrost(at)snowman(dot)net>, Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com>, PostgreSQL Developers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [HACKERS] pgbench - allow to store select results into variables
Date: 2019-01-10 21:23:34
Message-ID: alpine.DEB.2.21.1901102211350.27692@lancre
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Hello Alvaro,

> There's a lot of the new code in pgbench that can be simplified if we
> remove \cset.

I'm not very happy with the resulting syntax, but IMO the feature is
useful. My initial design was to copy PL/pgSQL "into" with some "\into"
orthogonal to \; and ;, but the implementation was not especially nice and
I was told to use psql's \gset approach, which I did.

If we do not provide \cset, then combined queries and getting results are
not orthogonal, although from a performance testing point of view an
application could do both, and the point is to allow pgbench to test the
performance impact of doing that.

There are other existing restrictions which are a arbitrary, eg you cannot
use prepared with combined. I wish not to add more of this kind of
restrictions, which are not "up to project standard" in my opinion. I may
try to remove this particular restriction in the future.

Not many people know that queries can be combined, but if you are
interested in latency that is really an interesting option, and being able
to check how much can be gained from doing that is a point of a tool like


In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message David Rowley 2019-01-10 21:47:55 Re: speeding up planning with partitions
Previous Message Robert Haas 2019-01-10 21:15:34 Re: MERGE SQL statement for PG12