> > I'm fairly sure that the query snapshot is established at Bind time, > which means that this SELECT will run with a snapshot that indeed > does not see the effects of the UPDATE. > > 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? Shay
