Chris Smith wrote:
> G'morning (or as appropriate for your time zone),
>
> I'm working on refactoring some code from AbstractJdbc1Statement, and there
> are comments and design all over the place indicating or assuming that the
> isSingleStatement, isSingleDML, and isSingleSelect methods are terribly
> expensive. As far as I can see, though, they aren't! isSingleStatement is
> implicitly calculated when parsing the query, and the other two involve a
> single calls to each of String.trim, String.toLowerCase, and
> String.startsWith. I suppose the String.toLowerCase might be an issue for
> absolutely gigantic queries, but it looks like we could deal with that by
> simply doing a substring to grab the first seven letters before doing the
> compare.
>
> Anyone disagree?
When I put that code in I was trying to keep the cost of queries that
didn't need to be transformed (due to non-query reasons e.g. state of
autocommit) to a minimum -- the current approach is certainly cheaper
and probably generates less garbage than the more obvious approach, but
I don't know by how much. At the time it was a fairly big change and I
was trying to preempt objections :)
Also please don't reparse on each execution (which is the other thing
that isSingleSelect and friends try to avoid) .. my use case for this is:
prepare statement once
execute statement 100k times with different parameters
keep statement around for later reuse
or the equivalent via batch updates. This currently chews a *lot* of CPU
on the Java side while executing -- on the order of a 50/50 split
between Java and the backend. I've been trying to reduce the JDBC
overhead via things like isSingleSelect.
However this use case seems to be common elsewhere:
prepare statement
execute statement with some parameters
discard statement
and we need to support both.
-O
