On 2016-08-16 21:40:32 -0400, Tom Lane wrote: > Andres Freund <and...@anarazel.de> writes: > > On 2016-07-31 17:57:12 -0400, Tom Lane wrote: > >> 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. > > > 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. > > I do not think that would move the needle noticeably, because we'd still > have to do basically all the same work, due to not knowing whether the > statement is going to be used over again. If we'd specified that the > unnamed statement could be used only once, and that the unnamed portal > had to be executed to completion on first use, there would be more room > for optimization. The joys of hindsight :-(
ISTM that with the current prepared statement search path behaviour (i.e. we replan on relevant changes anyway), we can store the unnamed statement's sql for that case. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
