Re: eWeek Poll: Which database is most critical to your

[snip]
>>----------------------------------------------------------------------
---------------
Thought for the day:
Caching this stuff could very easily exhaust the entire server disk
space in a jiffy.
Any lists stashed in memory will take away from database performance for
normal sorts
of queries.  Any lists stashed on disk will have to be read again.
Where is the big
savings?
<<----------------------------------------------------------------------
---------------
Sure. It would

a) make many queries faster

b) make client libs (ODBC/JDBC/ECPG) faster and simpler by not forcing
them to fake it.

But there is also a big class of applications that would benefit much
more from caching exact queries.

And it will make us as fast as MySQL for 100000 consecutive calls of
SELECT MAX(N) FROM T ;)
>>----------------------------------------------------------------------
---------------
Try as I might, I can't think of anything that could possibly be more
useless than that.
;-)

I agree that some web apps might benefit mightily with a careful plan
for this notion.
Maybe a special function/procedure call is in order.

If someone wants to explore this stuff, I'm all for it.  But I think it
needs careful
thought.  I suspect that:
1.  The work for retaining ACID properties of the database is ten times
harder than
anyone cares to imagine with changes of this nature.
2.  The benefit for most apps will be small, and will be negative if not
implemented
properly.
3.  The functionality can *already* be achieved by user applications
simply by holding
open your own cursors and reusing them.

For whoever wants to tackle this thing, I say, "GO for it!"
But go for it with both eyes open.

I don't think it should be anyone's priority.  But that is just because
it isn't very
interesting to me.  Maybe other people are a lot more keen on it.
<<----------------------------------------------------------------------
---------------