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
-----BEGIN PGP SIGNED MESSAGE-----
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.

Dan.

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

iD8DBQFBQF+RIv0S4qsbfuQRAsh7AJ4/M73uTaULCVRLlNuw8NjuY8CCbwCgy7Gf
cxAQMLT6zgcYp2otk2AzUnE=
=PjsA
-----END PGP SIGNATURE-----


Mime
View raw message