Re: Caching driver on pgFoundry?

On 6-sep-2007, at 11:40, Oliver Jowett wrote:

> Paul van den Bogaard wrote:
>
>> For the ones you describe could it be that the dbase layer is just
>> storage and not part of the (critical) performance path?
>
> Right, in our case we keep all state in memory as the primary
> representation (and maybe replicated across a cluster) and some
> specific state is also asynchronously written to disk via a RDBMS
> so that it survives a cluster restart. Performance of the write-
> back step is still important as it affects things like our MTTR
> from a complete database+cluster failure, but it does not directly
> affect the call throughput / latency.
>
>> If the database related work is critical in performance/throughput
>> than caching is a welcome technology.
>
> Well no not necessarily because *statement caching does nothing
> that you can't do directly in your application anyway*. For example
> in our case we would get no additional benefit from statement
> caching because we (as a JDBC client) already hold on to statement
> objects that we know we're going to reuse, i.e. we're already doing
> our own caching, and smarter than a generic layer can do because we
> have better knowledge of how we use our queries.

If all ISVs would do it intelligently than I would have been out of
a job :-). I definitely agree. There is only one who can (should)
know best and that is the application writer. However I found this is
a rare situation. On the other hand if you do not need this most
optimal situation than indeed it would be very helpfull if this layer
in between would do it for you.
>
> Statement caching is really a "go faster" switch when you don't
> want to (or cannot) optimize the application code, or where the
> exact query strings are unpredictable. But again it's not something
> that *has* to be implemented in the driver, as far as I can tell
> there's nothing there that can't be done by a layer between the
> client and the real driver.

I think from an implementation point of view you can build in and/or
directly on top the JDBC layer. From a performance point of view I do
not expect a significant advantage for one or the other either.

--Paul

>
> -O

------------------------------------------------------------------------
---------------------
Paul van den Bogaard
Paul(dot)vandenBogaard(at)sun(dot)com
CIE -- Collaboration and ISV Engineering, Opensource Engineering group

Sun Microsystems, Inc phone: +31
334 515 918
Saturnus 1
extentsion: x (70)15918
3824 ME Amersfoort mobile: +31
651 913 354
The Netherlands
fax: +31 334 515 001