Horton

Thread

Commits

  1. pgbench: Remove \cset

  1. Removing \cset from pgbench

    Alvaro Herrera <alvherre@2ndquadrant.com> — 2019-02-02T13:15:31Z

    Hello

In reply to https://postgr.es/m/alpine.DEB.2.21.1901102211350.27692@lancre
wherein Fabien wrote:

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

We very briefly discussed this topic at FOSDEM pgday.  My feeling on the
general opinion is that there's appreciation for \gset in general, but
that people feel that \cset is too much cruft to take for not enough
additional added value (compared to great value delivered by \gset).

What I'm going to do now is to write a patch to remove the \cset part of
the commit and post it, intending to push at some point next week.
If somebody has grown really fond of \cset, they can work on a patch to
implement it properly, which it isn't now.

Thanks

-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

  2. Re: Removing \cset from pgbench

    Fabien COELHO <coelho@cri.ensmp.fr> — 2019-02-03T07:37:17Z

    Hola Alvaro,

> In reply to https://postgr.es/m/alpine.DEB.2.21.1901102211350.27692@lancre
> wherein Fabien wrote:
>
>> 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.
>
> We very briefly discussed this topic at FOSDEM pgday.  My feeling on the
> general opinion is that there's appreciation for \gset in general, but
> that people feel that \cset is too much cruft to take for not enough
> additional added value (compared to great value delivered by \gset).
>
> What I'm going to do now is to write a patch to remove the \cset part of
> the commit and post it, intending to push at some point next week.
> If somebody has grown really fond of \cset, they can work on a patch to
> implement it properly, which it isn't now.

My usless 0.02€:

I'm willing to implement it properly. Do you have any advice?

For me the issue comes from the fact that postgres silently ignores empty 
queries, i.e. on:

   SELECT 1 \; \; SELECT 2;

Three queries are sent, the middle one empty, but two results returned 
(PGRES_TUPLES_OK, PGRES_TUPLES_OK) instead of (PGRES_TUPLES_OK, 
PGRES_EMPTY_QUERY, PGRES_TUPLES_OK). However, on:

   ;

You do have an PGRES_EMPTY_QUERY result. How to deal cleanly and simply 
with that?

Removing the "skip empty query" optimizations would remove the "it does 
not work with empty queries" documentation warning that I understood Tom 
complains about. It may have a little impact on "psql" implementation to 
keep the "show the last non-empty result" behavior on combined queries.

Providing non-orthogonal features (eg combined queries cannot use some 
options, such as -M in pgbench) is as much substandard as awkward 
optimizations like the above.

An alternative is to detect whether a query is empty, but that complicates 
the lexing phase to detect "\; <spaces and comments only> \;" and adjust 
the query count to match variable setting to their queries: one version of 
the patch kept the position of embedded semi-colons so as to be able to 
check that only spaces appear (comments are removed by the lexer). Because 
this was seen as awkward code working around awkward protocol behavior for 
an unlikely corner case, it was removed in the reviewing process and the 
limitation was documented instead.

-- 
Fabien.

  3. Re: Removing \cset from pgbench

    Fabien COELHO <coelho@cri.ensmp.fr> — 2019-03-23T06:20:59Z

    Hola Álvaro,

> What I'm going to do now is to write a patch to remove the \cset part of
> the commit and post it, intending to push at some point next week.

Per your request, here is a patch which removes \cset from pgbench. Sigh.

-- 
Fabien.

  4. Re: Removing \cset from pgbench

    Fabien COELHO <coelho@cri.ensmp.fr> — 2019-03-23T07:57:24Z

    >> What I'm going to do now is to write a patch to remove the \cset part of
>> the commit and post it, intending to push at some point next week.
>
> Per your request, here is a patch which removes \cset from pgbench. Sigh.

Again, only the removal is a little deeper. This lifts the constraint 
about not using empty queries in a compound statement, at the price of 
some added logic to detect the last result.

-- 
Fabien.

  5. Re: Removing \cset from pgbench

    Alvaro Herrera <alvherre@2ndquadrant.com> — 2019-03-25T15:22:57Z

    On 2019-Mar-23, Fabien COELHO wrote:

> > Per your request, here is a patch which removes \cset from pgbench. Sigh.
> 
> Again, only the removal is a little deeper. This lifts the constraint about
> not using empty queries in a compound statement, at the price of some added
> logic to detect the last result.

Thank you very much!  I've pushed this.

-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services