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.


Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to