Re: how good is PostgreSQL

> It seems to me that tracking the list of cached queries and watching for
> queries that might invalidate them adds a lot of complexity to the back
end
> and the front end still has to establish the connection and wait transfer
> the data over the socket.

I really don't think that it would. Checking to see if you have a query
(a hash lookup) is very, very cheap relative to normally processing a query,
I would think.

And invalidating cache entries would also be very, very cheap compared to
the normal activity of the database. Assuming hashes are done correctly, it
would probably be done much, much faster than any query could execute. If
software caches can increase the performance of disk drives that have
latencies in thousandths of seconds, I'm sure they could help with queries
that take hundredths or tenths of seconds. ; )

> On a more practical level, a backend solution would require someone with
> fairly detailed knowlege of the internals of the backend. A front end
> solution can more likely to be implemented by someone not as knowlegable.

Yeah. I was hoping that one of the developpers would say "oooh... that
would rock. We should do that." : )

> One of the big advantages of your technique is there is no code change at
> the application level. This means less database lock-in. Maybe that is a
> disadvantage too. ;-)

I'm sure that someone with a better understanding of the theory associated
with cache invalidation would design a better algorithm that I would, but it
seems that even a fairly rudimentary implementation would seriously increase
performance.

steve