Re: Analysis on backend-private memory usage (and a patch)

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Analysis on backend-private memory usage (and a patch)
Дата
Msg-id 12587.1378328209@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Analysis on backend-private memory usage (and a patch)  (Heikki Linnakangas <hlinnakangas@vmware.com>)
Ответы Re: Analysis on backend-private memory usage (and a patch)  (Heikki Linnakangas <hlinnakangas@vmware.com>)
Список pgsql-hackers
Heikki Linnakangas <hlinnakangas@vmware.com> writes:
> One fairly simple thing we could do is to teach catcache.c to resize the 
> caches. Then we could make the initial size of all the syscaches much 
> smaller.

I think this is attractive for the *other* reason you mention, namely
preserving reasonable performance when a catcache grows larger than
expected; but I'm pretty skeptical of nickel-and-diming caches that are
already really small.  Is it really worth cutting the TSPARSER caches
from 4 pointers to 2 for instance?

What concerns me about initially-undersized caches is that we'll waste
space and time in the enlargement process.  I'd suggest trying to get some
numbers about the typical size of each cache in a backend that's done a
few things (not merely started up --- we should not be optimizing for the
case of connections that get abandoned without running any queries).
Then set the initial size to the next larger power of 2.
        regards, tom lane



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

Предыдущее
От: Tomas Vondra
Дата:
Сообщение: Re: [rfc] overhauling pgstat.stat
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: [PERFORM] encouraging index-only scans