|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|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
> 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
|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|