Re: pgbench - allow to store select results into variables

Hello Tom,

>> Sending a batch of requests is a feature of libpq which is accessible
>> through pgbench by using "\;", although the fact is not documented. It
>> makes sense for a client to send independent queries together so as to
>> reduce latency.
>
> You're putting an awful lot of weight on an unsupported assertion about 
> latency.

For support, I would submit that many applications today are web/mobile 
apps which are quite sensitive to latency. See for instance the Fast 2016 
white paper by people at Google which discusses in depth "tail latency" as 
a key measure of quality for IO systems used for live services, or the new 
HTTP2 protocole (based on Google spdy) which aims at reducing latency 
through multiple features (compression, serveur push, pipelining...).

> If a user cares about that, why would she not simply merge the
> commands into "SELECT 1, 2, 3 \into one two three" ?

Because the code would look pretty awful:

   SELECT (SELECT first data FROM ... JOIN ... WHERE ... ),
          (SELECT second data FROM ... JOIN ... WHERE ...),
          (SELECT third data FROM ... JOIN ... WHERE ...);

> And I still say that what you're proposing might be easy right now, but
> it might also be next door to impossible in a refactored implementation.

I do not understand. There is one "multi" sql-command followed by a meta 
command, and somehow a refactor implementation would have troubled with 
that?

> I don't think we should go there on the basis of a weak argument about
> latency.  \into should retrieve data only from the last PGresult.

This looks pretty arbitrary: Why not the first one, as I asked for it 
first? Anyway, why allowing to send several queries if you are not allowed 
to extract their results.

-- 
Fabien.