db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel John Debrunner <...@debrunners.com>
Subject Re: Ideas for optimization
Date Thu, 09 Sep 2004 13:50:10 GMT
Hash: SHA1

Jan Hlavaty wrote:
> Daniel John Debrunner wrote:
>> The required steps would be something like
>> 1) During parse phase convert every ConstantNode to a ParameterNode
>> somehow storing the associated value (and setting the type of the
>> ParameterNode)
>> 2) Generate a text form of the SQL statement from the current modified
>> tree, where the constants are replaced with question marks.
>> 3) Re-compile statement, looking in cache etc.
>> 4) Somehow get the saved parameter values and set them into the
>> parameter set of the newly compiled statement. Somehow hide the
>> parameters from the user's JDBC object (e.g. PreparedStatement)
>> 5) Finally execute :-)
> You're taking the suggestion too literally ;-)
> It would be easier and cleaner to build support for this optimization
> directly into the query compiler.
> So that any statement with constants in it would compile into a compiled
> execution plan with constant parameters... the same plan, no matter the
> values of parameters.
> Make it automatically treat any constants in the SQL as "internal"
> parameters. Don't let this stuff overflow outside into JDBC and other
> unrelated stuff.
> Jan

That's exactly what I was describing. :-)
The compiled plan (statement) cache lookup is based upon the text of the
SQL statement, that's why the internal code would need the re-write.


Version: GnuPG v1.2.5 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org


View raw message