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

From: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
To: Michael Paquier <michael(at)paquier(dot)xyz>
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 13:58:50
Message-ID: alpine.DEB.2.21.2004021437440.16227@pseudo
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


Michaël,

>> ISTM that I submitted a patch to test whether a variable exists in pgbench,
>> like available in psql (:{?var} I think),
>
> 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.

Sure. I meant that the feature would make sense to write benchmark scripts
which would use aset and be able to act on the success or not of this
aset, not to resurrect it for a hidden coverage test.

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

Nope.

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

The idea is that a scalar is simpler and readable to write in the simple
case than a perl array. Now maybe qw() could have done the trick.

--
Fabien.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2020-04-02 14:20:15 Re: WIP/PoC for parallel backup
Previous Message Jehan-Guillaume de Rorthais 2020-04-02 13:49:15 Re: [BUG] non archived WAL removed during production crash recovery