Brian Cocks wrote:
>
> I'm wondering how much improvement this caching is over the database caching
> the parsed SQL statement and results (disk blocks)?
>
> In Oracle, if you issue a query that is cached, it doesn't need to be parsed.
> If the resulting blocks are also cached, there isn't any disk access. If the
> database is tuned, you should be able to get stuff out of cache over 90% of
> the time. I don't know what other databases other than Oracle do.
Oracle is clever in this respect - and you are right if you tune
correctly you should hit the cache ...
But may other DB's do not have a shared executition plan / results
cache. MySQL, msql and postgreSQL do not. As far as I am aware Sybase
only has an execution plan cache that is per connection (could be wrong
here).
The MySQL developers have got a SELECT CACHED idea, where you can define
a statement as cacheable, and further calls to SELECT CACHE will return
the cached results - this is all on the todo list with no fixed date.
> What are the advantages of implementing your own cache? Is there any reason
> other than speed?
Could be wrong but no - and it has a bad point in that it introduces an
added layer of complexity .....
I am certainly interested as accessing a local cache should be an order
of magnitude faster than asking a buzy DB.
Greg Cope
>
> --
> Brian Cocks
> Senior Software Architect
> Multi-Ad Services, Inc.
> [EMAIL PROTECTED]
