|From:||Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>|
|To:||Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>|
|Cc:||Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, PostgreSQL Developers <pgsql-hackers(at)postgresql(dot)org>|
|Subject:||Re: pgbench - allow to store select results into variables|
|Views:||Raw Message | Whole Thread | Download mbox|
>> Then you would get the -r cut at the end of the compound command. Thus the
>> current version gives full control of what will appear in the summary. If
>> I change "\into xxx\n" to mean "also cut here", then there is less control
>> on when the cut occurs when into is used.
> So it means that position of \into affects where a compound command gets
> cut for -r display. I was just wondering if that was unintentional.
Yes, but it happens to work reasonnably:-)
>> The other thing I have considered is whether to implemented a "\gset"
>> syntax, as suggested by Pavel and Tom. Bar the aesthetic, the main issue I
>> have with it is that it does not work with compound commands, and what I
>> want is to get the values out of compound commands... because of my focus
>> on latency... so basically "\gset" does not do the job I want... Now I
>> recognize that other people would like it, so probably I'll do it anyway
>> in another patch.
> So, psql's \gset does not work as desired for compound commands (viz. it
> is only able to save the result of the last sub-command).
> You need to use \gset with each sub-command separately if no result
> should be discarded. Because of undesirable latency characteristics of
> sending multiple commands, you want to be able to modify compound
> command handling such that every sub-command's result could be saved.
> In that regard, it's good that pgbench does not use PQexec() which only
> returns the result of the last sub-command if a compound command was
> issued through it.
> doCustom() currently discards all results by issuing discard_response().
> You propose to change things such that results are intercepted in a new
> function read_response(), values assigned to intovars corresponding to
> each sub-command, and then discarded. The intovars arrays are allocated
> within each sub-command's Command struct when parsing the compound command
> based on where \into is located wrt to the sub-command.
> So, most of the code in the patch is about handling compound statements to
> be be able to save results of all sub-commands, not just the last.
Yep. Previously pgbench did not need to handle compounds commands which
where just seen as one large string.
Note that the added machinery is also a first step to allow the handling
of prepared statements on compounds command, which I think is a desirable
feature for benchmarks.
> Do you think it would be OK to suffer the bad latency of multiple round
> trips and implement a version of \into (or \gset or \ginto) for pgbench
> scripts that behaves exactly like psql's \gset as a first step?
I do not see gset as a reasonnable "first step" because: (0) "\into"
already works while "\gset" in pgbench will need some time that I do not
have at the moment (1) it is not what I want/need to do a clean bench (2)
the feature is not orthogonal to compounds statements -- which is what I
want -- (3) I do not like the "implicit" naming thing -- but this is
really just a matter of taste.
I simply recognize that Peter & Tom have a point: whatever I think of gset
it is there in "psql" so it makes some sense to have it as well in
"pgbench", so I agree to put that on my pgbench todo list.
> But you say you will do it as another patch.
Yep. I suggested another patch because it is a different feature and
previous submissions where I mixed features, even closely related ones,
all resulted in me having to separate the features in distinct patches.
> By the way, I tend to agree with your point about \gset syntax being
> suitable (only) in a interactive context such as psql; it's not as
> readable as \into x y ... when used in a script.
Yep, but as people already know it, it makes sense to provide it as well
at some point.
|Next Message||Heikki Linnakangas||2016-09-18 11:14:51||Re: ecpg -? option doesn't work in windows|
|Previous Message||Pavel Stehule||2016-09-18 09:53:47||Re: patch: function xmltable|