Re: pgbench - add \aset to store results of a combined query

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
Cc: Ibrar Ahmed <ibrar(dot)ahmad(at)gmail(dot)com>, PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: pgbench - add \aset to store results of a combined query
Date: 2020-04-02 08:03:36
Message-ID: 20200402080336.GF112468@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Apr 02, 2020 at 08:08:08AM +0200, Fabien COELHO wrote:
> ISTM that I submitted a patch to test whether a variable exists in pgbench,
> like available in psql (:{?var} I think), but AFAICS it did not pass. Maybe
> I should resurect it as it would allow to test simply whether an empty
> result was returned to aset, which could make sense in a bench script (get
> something, if it does not exist skip remainder… I can see some interesting
> use cases).

Not sure if improving the readability of the tests is a reason for
this patch. So I would suggest to just live with relying on debug()
for now to check that a variable with a given prefix exists.

> It does not need to create an UNLOGGED table, a mere "WHERE FALSE" suffices.

Good point, that's cheaper.

> I do not understand why you removed the comment about meta which makes it
> false, so I added something minimal back.

* type SQL_COMMAND or META_COMMAND
- * meta The type of meta-command, or META_NONE if command is SQL
+ * meta The type of meta-command. On SQL_COMMAND: META_NONE/GSET/ASET.

Oh, OK. I see your point. Sorry about that.

>> Perhaps we should also have a test where we return more than 1 row for
>> \get? The last point is unrelated to this thread though.
>
> Yes, but ISTM that it is not worth a dedicated patch… so I added a test
> similar to the one about empty aset.

Thanks. So, it looks like everything has been addressed. Do you have
anything else in mind?

NB: I think that it is really strange to not use an array for the
options in subroutine pgbench() of 001_pgbench_with_server.pl.
Shouldn't this be an array of options instead? The current logic of
using a splitted string is weak when it comes to option quoting in
perl and command handling in general.
--
Michael

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kyotaro Horiguchi 2020-04-02 08:25:40 EINTR while resizing dsm segment.
Previous Message movead.li@highgo.ca 2020-04-02 07:51:52 Re: A bug when use get_bit() function for a long bytea string