Oliver Jowett wrote:
> John Lister wrote:
>
>> Hi, i was wondering if there is any reason why the query preparation is
>> done when the query is executed instead of when the preparedStatement is
>> created.
>>
>
> It would be an extra network round-trip on every query, and there's no
> requirement to prepare it early.
>
Just going through the code again and please correct me if i'm wrong,
but at the moment there is unnecessary network traffic/latency. Assuming
a PreparedStatement, every time execute is called, sendParse and
sendDescribePortal are called (the former checks if a server side
prepared statement has been created and aborts if so). Admittedly
sendParse is only called as many times as setPrepareThreshold is set to
(which admittedly may be as low as 1)
Apart from the use of unnamed statements/portals within a multi threaded
environment which complicates things with parsing, i would have thought
you could get away with calling describe(portal) just once.
I appreciate that it would need a lot of refactoring to move things
around, but are there any objections?
Also, i don't know how many server side prepared statements/portals
postgresql supports (hopefully memory limited) but would it also not
make more sense to make all preparedStatements actually be server side
preparedStatements. I can't see what overhead this would add apart from
named statements/portals
I'd be happy to look into this if there was support...
Thanks