Re: Caching of frequently used objects

Поиск
Список
Период
Сортировка
От Yann Michel
Тема Re: Caching of frequently used objects
Дата
Msg-id 20050119181443.GA5238@zong.spline.inf.fu-berlin.de
обсуждение исходный текст
Ответ на Re: Caching of frequently used objects  (Bruno Wolff III <bruno@wolff.to>)
Ответы Re: Caching of frequently used objects  (Neil Conway <neilc@samurai.com>)
Список pgsql-hackers
Hi,

On Wed, Jan 19, 2005 at 11:54:50AM -0600, Bruno Wolff III wrote:
> 
> > objects will use the default one. I think even count(*) queries could
> > benefit from this buffer-splitting due to indexes might be pinned to
> > this buffer pool. 
> 
> This wouldn't have any special effect on count(*) queries.

O.K. not full, but due to indexes may be used for some of this queries.
the indexes themselves could be pinned into the special buffer pool and
need not to be loaded into the cache.

> > So my question is if there is already any comparable functionality or if
> > it is planed. I didn't find any comparable feature or TODO on the list.
> 
> The developers seem to feel that having postgres and the os decide
> what should be cached based on observed usage is better than having
> the DBA do this.

The effect while using a seperate buffer cache for different objects,
i.e. using a lru list would stay the same. There would be "only" two
more than one buffer cache for a certain object gourp or class. In dwh
systems you would normally use a special buffer pool for your dimensions
to pin them into memory so that they are not rolled out by any large
fact table at all. In fact they can become rolled out but this may only
happen if an object belonging to the same pool should be loaded into the
cache. This is more or less the fact if the dba has sized the pin-cache
to small.

Regards,
Yann


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

Предыдущее
От: Manfred Koizar
Дата:
Сообщение: Re: Refactoring
Следующее
От: Heikki Linnakangas
Дата:
Сообщение: Two-phase commit for 8.1