Re: Query caching

>  Sounds interesting, I  certainly have reasons to play bad  guy, but
that's
> what I always do, so nevermind :)

  That's OK.  Somebody has to be a realist. : )

>  However, there's  one major point where  I disagree. Not that  I have
real
> reasons to,  or observation or analysis  to background my position,  just
a
> feeling. And the feeling is  that connection/query cache should be
separate
> from DBMS server itself.
>  Several things  come to the  mind right  off, like possibilities  to
cache
> connections  to different  sources, like  PGSQL and  Oracle,

   That would be a benefit if you're running multiple DBMS' in the house -
and you're certainly welcome to do something like that as a standalone
package.  ; )   I think it would be terrific if PostgreSQL could have the
feature added to it, which would (a) give it a big performance benefit, (b)
let it take advantage of already-written code, and (c) make one less machine
and service to administer.

> as  well as  a
> chance  to run  this cache  on  a separate  box that  will perform
various
> additional functions, like load balancing. But that's right on the
surface.
>  Still in doubt....

  Yes, load-balancing would be another good factor.  However, to my (very
limitted) knowledge, there aren't any truly good ways of splitting up
database work.  If you're doing nothing but selects, it would be easy.  But
when updates come around, it gets hairier - and when you try to try for
dynamic continuity-checking and database rebuilding, it gets very ugly.   If
there are any systems that get around those without huge performance hits,
I'd love to hear about it.

   (Of course, if you have lots of money, a Beowolf-style cluster with high
bandwidth, low-latency interconnects becomes desireable.  But that's a
different ballgame.)

   However, there is one other possibility:  With caching, your servers
might see enough of a performance increase that you wouldn't need to
load-balance them. : )

steve