On Tue, Apr 20, 2010 at 5:05 PM, Kris Jurka <books@ejurka.com> wrote:
> The reason this is not done is that the mechanism used for fetching a piece
> of the results at a time can change the query plan used if using a
> PreparedStatement. There are three ways to plan a PreparedStatement:
>
> a) Using the exact parameter values by substituting them directly into the
> query. This isn't really "planned" as you can't re-use it at all. This is
> only available using the V2 protocol.
>
> b) Using the parameter values for statistics, but not making any stronger
> guarantees about them. So the parameters will be used for evaluating the
> selectivity, but not to perform other optimizations like contraint_exclusion
> or transforming a LIKE operation to a range query. This is the default plan
> type the JDBC driver uses.
Hmm. I didn't think this was possible. How are you doing this?
> c) Planning the query with no regard for the parameters passed to it. This
> is the plan type the JDBC driver uses when it sees the same
> PreparedStatement being re-used multiple times or when it is respecting
> setFetchSize and allowing for partial results.
>
> We must use (c) for partial results instead of (b) because of some
> limitations of the server. Currently you cannot have two statements of type
> (b) open on the same connection. So since the driver can't know if the user
> will issue another query before fetching the remainder of the first query's
> results, it must setup the first query to be of type (c) so that multiple
> statements can exist simultaneously.
>
> Switching the default plan type to (c) will cause a significant number of
> complaints as performance on some queries will go into the tank. Perhaps we
> could have a default fetchSize for plain Statements as it won't affect the
> plan. I could also see making this a URL parameter though so it could be
> set as the default with only a configuration, not a code change.
...Robert
