Craig Ringer wrote: > I think it's mostly of interest to app authors and driver developers > and that's what it's aimed at. pg_restore could benefit a lot too.
Wouldn't pgbench benefit from it? It was mentioned some time ago [1], in relationship to the \into construct, how client-server latency was important enough to justify the use of a "\;" separator between statements, to send them as a group. But with the libpq batch API, maybe this could be modernized with meta-commands like this: \startbatch ... \endbatch which would essentially call PQbeginBatchMode() and PQsendEndBatch(). Inside the batch section, collecting results would be interleaved with sending queries. Interdepencies between results and subsequent queries could be handled or ignored, depending on how sophisticated we'd want this. This might also draw more users to the batch API, because it would make it easier to check how exactly it affects the performance of specific sequences of SQL statements to be grouped in a batch. For instance it would make sense for programmers to benchmark mock-ups of their code with pgbench with/without batching, before embarking on adapting it from blocking mode to asynchronous/non-blocking mode. [1] https://www.postgresql.org/message-id/alpine.DEB.2.20.1607140925400.1962%40sto Best regards, -- Daniel Vérité PostgreSQL-powered mailer: http://www.manitou-mail.org Twitter: @DanielVerite -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
