Re: per table random-page-cost?

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(dot)Grittner(at)wicourts(dot)gov
> wrote:

> Greg Stark <gsstark(at)mit(dot)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