On Apr 16, 2008, at 8:48 PM, Jeff Rogers wrote:
I've been told this by every oracle dba I've worked with and the
performance gains I've seen by moving to prepared statements is
generally quite small unless the sql is horrendously complex, and
even then the backends appear to do caching of query plans anyway
and so essentially use prepared queries implicitly even when the
application code doesn't. sqlite even throws particular errors when
something happens to invalidate its cached query plans.
True of Oracle, not true, for instance, of Postgres.
However, parsing of a SQL statement's extremely fast (how often are
queries longer than a couple dozen lines in your typical web app?),
what needs caching is the execution plan generated query optimizer.
However, that can be a bit dicey unless your data's nicely distributed
and you can have confidence that one plan will work about as well as
any other the optimizer might generate, and that the very first query
happens to generate such a plan.
And that you gather analyzer stats and clear the query plan cache
fairly often ...
----
Don Baccus
http://donb.photo.net
http://birdnotes.net
http://openacs.org
--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]>
with the
body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject:
field of your email blank.
