Re: pgbench - allow to store select results into variables

From: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
To: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
Cc: Tatsuo Ishii <ishii(at)sraoss(dot)co(dot)jp>, rafia(dot)sabih(at)enterprisedb(dot)com, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>, Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL Developers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pgbench - allow to store select results into variables
Date: 2017-11-04 11:05:39
Message-ID: alpine.DEB.2.20.1710251209330.24229@lancre
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


Hello Pavel,

>> Here is a v13, which is just a rebase after the documentation xml-ization.

Here is a v14, after yet another rebase, and some comments added to answer
your new comments.

> I am looking to this patch.
>
> Not sure if "cset" is best name - maybe "eset" .. like embeded set?

I used c for "compound", because they compound SQL commands.

Now I do not have a very strong opinion, only that it should be some
letter which some logic followed by "set".

The variables and fields in the source currently use "compound"
everywhere, if this is changed they should be updated accordingly.

ISTM that the ";" is embedded, but the commands are compound, so
"compound" seems better word to me. However it is debatable.

If there some standard naming for the concept, it should be used.

> The code of append_sql_command is not too readable and is not enough
> commented.

Ok. I have added comments in the code.

> I don't understand why you pass a param compounds to append_sql_command,
> when this value is stored in my_command->compound from create_sql_command?

This is the number of compound commands in the "more" string. It must be
updated as well as the command text, so that the my_command text and
number of compounds is consistant.

Think of one initialization followed by two appends:

SELECT 1 AS x \cset
SELECT 2 \; SELECT 3 AS y \cset
SELECT 4 \; SELECT 5 \; SELECT 6 AS z \gset

In the end, we must have the full 6 queries

"SELECT 1 AS x \; SELECT 2 \; SELECT 3 AS y \; SELECT 4 \; SELECT 5 \; SELECT 6 AS z"

and know that we want to set variables from queries 1, 3 and 6 and ignore
the 3 others.

> Or maybe some unhappy field or variable names was chosen.

It seems ok to me. What would your suggest?

--
Fabien.

Attachment Content-Type Size
pgbench-into-14.patch text/x-diff 21.2 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2017-11-04 11:08:31 Re: [POC] Faster processing at Gather node
Previous Message Noah Misch 2017-11-04 07:49:46 Re: [COMMITTERS] pgsql: Account for catalog snapshot in PGXACT->xmin updates.