Oleg Bartunov wrote:
>
> On Thu, 14 Oct 1999, Perrin Harkins wrote:
>
> > Date: Thu, 14 Oct 1999 17:53:15 -0700 (PDT)
> > From: Perrin Harkins <[EMAIL PROTECTED]>
> > To: Jeffrey Baker <[EMAIL PROTECTED]>
> > Cc: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]
> > Subject: Re: More on web application performance with DBI
> >
> > On Thu, 14 Oct 1999, Jeffrey Baker wrote:
> > > Zero optimization: 41.67 requests/second
> > > Stage 1 (persistent connections): 140.17 requests/second
> > > Stage 2 (bound parameters): 139.20 requests/second
> > > Stage 3 (persistent statement handles): 251.13 requests/second
> >
> > I know you said you don't like it because it has extra overhead, but would
> > you mind trying stage 3 with prepare_cached rather than your custom
> > solution with globals? For some applications with lots of SQL statements,
> > the prepare_cached appraoch is just much more manageable.
>
> Some databases doesn't support caches of prepared plans.
> PostgreSQL for example. So I think Jeffrey's approach is more
> generic. But I agree with you if database supports this feature
> it's worth to use it.
Actually, prepare_cached is all about avoiding steps in DBI on the
client side. It is independent of the database's query plan cache.
Anyway, Jeffrey's benchmark of prepare_cached was enough to convinve me
that using your own cache of prepared queries is more efficient. I do
worry though about what would happen if the database connection dropped
or something. I expect prepare_cached would recover from this pretty
well.
- Perrin
