Re: PostgreSQL Process memory architecture

Поиск
Список
Период
Сортировка
От Merlin Moncure
Тема Re: PostgreSQL Process memory architecture
Дата
Msg-id CAHyXU0zhYLJc2jgQs1_YjtqfoZmjm+5sOvNbV9H+2vmtyBR0Jw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: PostgreSQL Process memory architecture  (Stephen Frost <sfrost@snowman.net>)
Список pgsql-hackers
On Mon, May 27, 2013 at 7:29 AM, Stephen Frost <sfrost@snowman.net> wrote:
> * Atri Sharma (atri.jiit@gmail.com) wrote:
>> Yes, too many indexes wont hurt much.BTW,wont making too many indexes
>> on columns that probably dont have as many values as to deserve
>> them(so,essentially,indiscriminately making indexes) hurt the
>> performance/memory usage?
>
> I'd expect the performance issue would be from planner time more than
> memory usage- but if there is a serious memory usage issue here, then
> it'd be valuable to have a test case showing what's happening.  We may
> not be releasing the sys cache in some cases or otherwise have a bug in
> this area.

Note, backends do use private memory to cache various things
(relcache, etc).   Absolutely pathological workloads (tons of tables,
tons of (especially) views, etc can exercise this into the gigabytes
and there is no effective way to monitor and control it.  Normally,
it's not a very big deal though.

So, to be a bit more specific, the index *data* (like all on disk
structures) is buffered in shared memory.  But certain plans/metadata
stuff is in private memory.

merlin



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

Предыдущее
От: Jon Nelson
Дата:
Сообщение: Re: fallocate / posix_fallocate for new WAL file creation (etc...)
Следующее
От: Andres Freund
Дата:
Сообщение: Re: fallocate / posix_fallocate for new WAL file creation (etc...)