-----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-----
