On Tue, 2004-11-23 at 03:45, Darren Duncan wrote: > Or do statement handles hold on to limited database server resources > such that it is best to have them for as little time as possible, > meaning to have all of your execute() as close as possible to the > prepare() in the program execution?
To get any caching benefit then it seems pretty obvious (at least from where I sit) that some server resources will be held for the statement handle. The most expensive part of the "prepare" call is the optimization phase of the query - i.e. where the server analyzes the query and determines the optimium query plan. It's caching this information that makes subsequent calls of the same request fast. > I have a decision to make as to whether I should try, with a long > running program such as would run under mod_perl, to front-load all > the prepare() to when a process or thread starts, so each page > request only has execute(). Have you considered using prepare_cached() instead, and letting DBI worry about it? > The other option is to run them close together more or less like do() does. > > More broadly speaking, I wonder if it is possible to do prepares > prior to opening a database connection, so they can be reused through > multiple connections? Or if the system was never designed for this > sort of thing? The real answer to that is to write stored procedures... that's equivalent to having pre-prepared statements :-) (and no, you can't prepare() statements without a database connection.) Michael -- Michael Peppler Data Migrations, Inc. [EMAIL PROTECTED] http://www.peppler.org/ Sybase T-SQL/OpenClient/OpenServer/C/Perl developer available for short or long term contract positions - http://www.peppler.org/resume.html
