Re: How to keep a table in memory?

Kevin Grittner wrote:
> > . . .the abuse of such hints in applications I have seen is so
rampant as to
> > make me doubt the utility of adding them anyway.  It's true that by
adding
> > hints, you give a facility to a good, competent designer who has a
really

> I have trouble not seeing the point of any posts in this thread.
> Under our old, commercial database product, we had performance
> problems we addressed with a "named caches" feature -- you could
> declare a named cache of a particular size, and tweak some
> characteristics of it, then bind objects to it.  We came up with

Seems you simply fall in the competent category :-)

I know that another commercial product had introduced a pin table into
memory
feature for a few years, but dropped it again in the current release.
It seems the potential for wrongdoing is significant :-(
At least a "lock this table into memory" must be accompanied by an
"allow a max percentage of buffercache" and something that loads the
table on startup. But what do you do if it does not fit ?
Caching only parts of the table is useless for the mentioned use-case.

One aspect that has not been addressed is whether there is a way to
cluster/partition the table in a way that reduces/clusters the number of
pages that need to
be fetched by these not frequent enough but performance critical queries
?

This may solve the problem with a different approach.

Andreas