Andres Freund <and...@anarazel.de> writes: > FWIW, I've observed the same with (a bit) more complicated queries. A > part of this is that the extended protocol simply does > more. PQsendQueryGuts() sends Parse/Bind/Describe/Execute/Sync - that's > simply more work and data over the wire than a single Q message.
Yeah. The extended query protocol was designed to offer a lot of functionality that people had asked for, like plan re-use and introspection of the data types assigned to query parameters, but that doesn't come at zero cost. I think the tie-in to the plan cache is a significant part of the added overhead, and so is the fact that we have to iterate the per-message loop in PostgresMain five times not once, with overheads like updating the process title incurred several times in that. In hindsight it seems clear that what a lot of apps want out of extended protocol is only the ability to send parameter values out-of-line instead of having to quote/escape them into SQL literals. Maybe an idea for the fabled V4 protocol update is some compromise query type that corresponds precisely to PQexecParams's feature set: you can send parameter values out-of-line, and you can specify text or binary results, but there's no notion of any persistent state being created and no feedback about parameter data types. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers