> 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
