Kris Jurka wrote:
>
> On Wed, 19 May 2004, Oliver Jowett wrote:
>
>
>>Instead, how about something like:
>>
>> - For named statements, plan at Parse time always.
>> - For unnamed statements, plan at Bind time always.
>>
>>The assumption here is that if the client is using the unnamed
>>statement, it's unlikely that it will be repeatedly reusing that
>>statement with different parameter values so there is little benefit to
>>preserving the query plan at the cost of being unable to plan for
>>specific parameter values. If the client is using named statements,
>>there's no change in behaviour from the current approach, so presumably
>>the client knows what it's doing! :)
>
>
> I was under the impression that the query protocol would Parse once and
> then Bind/Execute for each execution of a statement.
Yes.
> If that's true we
> can't use the unnamed portal because it can be destroyed if a
> multithreaded app is using two Statements simultaneously. The lock on
> pgstream will be given up between executions of a statement.
By default we re-Parse on each subsequent execution. The Parse is only
skipped if there is a named statement corresponding to the query being
executed (i.e. we previously sent a named Parse and got a corresponding
ParseComplete back). So there's no threading issue, just the cost
(hopefully small if planning is not being done) of re-Parsing the
statement on each execution.
This is already in my v3 changes. The named-vs-unnamed distinction is
controlled by a query flag (QUERY_ONESHOT) rather than by whether the
query is parameterized or not -- it'll support unnamed statements that
have parameters with no changes. Currently QUERY_ONESHOT is only passed
when executing queries via the direct-execution Statement interface, but
it'd easy to hook up to the state of the useServerPrepare flag for the
PreparedStatement case.
-O
