Re: Is There Any Way ....

Поиск
Список
Период
Сортировка
От Lane Van Ingen
Тема Re: Is There Any Way ....
Дата
Msg-id EKEMKEFLOMKDDLIALABIOEEICDAA.lvaningen@esncc.com
обсуждение исходный текст
Ответ на Re: Is There Any Way ....  (Stefan Weiss <spaceman@foo.at>)
Ответы Re: Is There Any Way ....  (Mark Lewis <mark.lewis@mir3.com>)
Список pgsql-performance
Yes, Stefan, the kind of usage you are mentioning is exactly why I was
asking.

-----Original Message-----
From: pgsql-performance-owner@postgresql.org
[mailto:pgsql-performance-owner@postgresql.org]On Behalf Of Stefan Weiss
Sent: Tuesday, October 04, 2005 6:32 AM
To: pgsql-performance@postgresql.org
Subject: Re: [PERFORM] Is There Any Way ....


On 2005-09-30 01:21, Lane Van Ingen wrote:
>   (3) Assure that a disk-based table is always in memory (outside of
keeping
> it in
>       memory buffers as a result of frequent activity which would prevent
> LRU
>       operations from taking it out) ?

I was wondering about this too. IMO it would be useful to have a way to tell
PG that some tables were needed frequently, and should be cached if
possible. This would allow application developers to consider joins with
these tables as "cheap", even when querying on columns that are not indexed.
I'm thinking about smallish tables like users, groups, *types, etc which
would be needed every 2-3 queries, but might be swept out of RAM by one
large query in between. Keeping a table like "users" on a RAM fs would not
be an option, because the information is not volatile.


cheers,
stefan

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings



В списке pgsql-performance по дате отправления:

Предыдущее
От: Stefan Weiss
Дата:
Сообщение: Re: Is There Any Way ....
Следующее
От: "Jim C. Nasby"
Дата:
Сообщение: Re: Slow concurrent update of same row in a given table