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.
