Thanks for the help Tom and the others, I'll modify my sequence and report if I encounter any further issues.
On Sun, Oct 4, 2015 at 7:36 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Shay Rojansky <r...@roji.org> writes: > >> To my mind there is not a lot of value in performing Bind until you > >> are ready to do Execute. The only reason the operations are separated > >> in the protocol is so that you can do multiple Executes with a row limit > >> on each one, to retrieve a large query result in chunks. > > > So you would suggest changing my message chain to send Bind right after > > Execute, right? This would yield the following messages: > > > P1/P2/D1/B1/E1/D2/B2/E2/S (rather than the current > > P1/D1/B1/P2/D2/B2/E1/C1/E2/C2/S) > > > This would mean that I would switch to using named statements and the > > unnamed portal, rather than the current unnamed statement > > and named portals. If I recall correctly, I was under the impression that > > there are some PostgreSQL performance benefits to using the > > unnamed statement over named statements, although I admit I can't find > any > > documentation backing that. Can you confirm that the two > > are equivalent performance-wise? > > Hmm. I do not recall exactly what performance optimizations apply to > those two cases; they're probably not "equivalent", though I do not think > the difference is major in either case. TBH I was a bit surprised on > reading your message to hear that the system would take that sequence at > all; it's not obvious that it should be allowed to replace a statement, > named or not, while there's an open portal that depends on it. > > I think you might have more issues with lifespans, since portals go away > at commit whereas named statements don't. > > regards, tom lane >
