Re: PostgreSQL Process memory architecture - Mailing list pgsql-hackers

From Merlin Moncure
Subject Re: PostgreSQL Process memory architecture
Date
Msg-id CAHyXU0zhYLJc2jgQs1_YjtqfoZmjm+5sOvNbV9H+2vmtyBR0Jw@mail.gmail.com
Whole thread Raw
In response to Re: PostgreSQL Process memory architecture  (Stephen Frost <sfrost@snowman.net>)
List 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 by date:

Previous
From: Jon Nelson
Date:
Subject: Re: fallocate / posix_fallocate for new WAL file creation (etc...)
Next
From: Andres Freund
Date:
Subject: Re: fallocate / posix_fallocate for new WAL file creation (etc...)