On Tue, Aug 16, 2016 at 4:48 PM, Andres Freund <and...@anarazel.de> wrote: > One approach to solving this, without changing the protocol, would be to > "fuse" parse/bind/execute/sync together, by peeking ahead in the > protocol stream. When that combination is seen looking ahead (without > blocking), optimize it by handing it to something closer to > exec_simple_query() which also handles parameters. Even if we don't > recognize that pattern everytime, e.g. because later messages are in > different, not yet arrived, tcp packets, that'd speed up the common > case. As our client socket is nearly always is in non-blocking mode > these days, that shouldn't be too expensive.
I think this could possibly be done, but it seems a lot better to me to just bite the bullet and add a new protocol message. That was proposed by Tom Lane on July 31st and I think it's still by far the best and easiest idea proposed, except I think we could introduce it without waiting for a bigger rework of the protocol if we design the libpq APIs carefully. Most of the rest of this thread seems to have devolved into an argument about whether this is really necessary, which IMHO is a pretty silly argument, instead of focusing on how it might be done, which I think would be a much more productive conversation. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
