Well I think we need sone way to accomplish the same high level goal
of guaranteeing response times for latency-critical queries.
However my point is that cache policy is an internal implementation
detail we don't want to expose in a user interface.
--
Greg
On 2009-10-22, at 11:41 AM, "Kevin Grittner" <kevin.gritt...@wicourts.gov
> wrote:
Greg Stark <gsst...@mit.edu> wrote:
There is another use case which perhaps needs to be addressed: if
the user has some queries which are very latency sensitive and
others which are not latency sensitive.
Yes. Some products allow you to create a named cache and bind
particular objects to it. This can be used both to keep a large
object with a low cache hit rate from pushing other things out of the
cache or to create a pseudo "memory resident" set of objects by
binding them to a cache which is sized a little bigger than those
objects. I don't know if you have any other suggestions for this
problem, but the named cache idea didn't go over well last time it was
suggested.
In all fairness, PostgreSQL does a good enough job in general that I
haven't missed this feature nearly as much as I thought I would; and
its absence means one less thing to worry about keeping properly
tuned.
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
