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
You're putting an awful lot of weight on an unsupported assertion about
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
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.
Sent via pgsql-hackers mailing list (email@example.com)
To make changes to your subscription: