Re: [HACKERS] pgbench - allow to store select results into variables

From: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
To: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: 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
Date: 2019-01-06 18:29:45
Message-ID: alpine.DEB.2.21.1901061737560.30093@lancre
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


Hello Alvaro,

> I revised this patch a bit. Here's v25, where some finishing touches
> are needed -- see below. I think with these changes the patch would
> become committable, at least for me.

Thanks a lot for having a look a this patch, and improving it.

The updated version did not work, though, but the fix was easy.

I do not understand why you have removed the num_commands stuff, which
indeed is not very useful but could be for debugging. No big deal.

> I didn't like that you were adding an #include of psqlscan_int.h into
> pgbench.c, when there's a specific comment in the header saying not to
> do that,

Oops, I did not notice the comment.

> so I opted for adding a new accessor function on psqlscan.h.

Ok.

> I renamed some of your parameter additions. I think the new names are
> clearer, but they meant the +1's in your code are now in illogical
> places. (I moved some; probably not enough). Please review/fix that.

It needed some fixing. I understood that you suggest to avoid keeping the
last index and prefer the number of elements instead, so I applied it to
the Command struct as well.

> I think "gset" is not a great name for the new struct member;

Indeed.

> please find a better name. I suggest "targetvar" but feel free to
> choose a name that suits your taste.

Ok. Note that it is not a variable name but a prefix, so I named it
"prefix".

> There are two XXX comments. One is about a function needing a comment
> atop it.

Ok.

> The other is about realloc behavior. To fix this one I would add a new
> struct member indicating the allocated size of the array, then growing
> exponentially instead of one at a time. For most cases you can probably
> get away with never reallocating beyond an initial allocation of, say, 8
> members.

Yep. I guess I did it 1 by 1 because it should be a rare case and it was
saving a counter. I've done some exponential thing instead.

> In the docs, the [prefix] part needs to be explained in the \cset entry;
> right now it's in \gset, which comes afterwards. Let's move the
> explanation up, and then in \gset say "prefix behaves as in \cset".

I do not understand, the very same explanation text about prefix appears
in both entry? The examples are different, is that what you mean? They are
about different backslash commands, so they have an interest of their own.

Attached a v26 with I hope everything ok, but for the documentation that
I'm unsure how to improve.

--
Fabien.

Attachment Content-Type Size
pgbench-into-26.patch text/x-diff 31.0 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Mitar 2019-01-06 19:01:52 Adding a concept of TEMPORARY TABLESPACE for the use in temp_tablespaces
Previous Message Tom Lane 2019-01-06 17:16:07 Re: [PATCH] check for ctags utility in make_ctags