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
