Re: PostgreSQL Process memory architecture

From: Merlin Moncure <mmoncure(at)gmail(dot)com>
To: Stephen Frost <sfrost(at)snowman(dot)net>
Cc: Atri Sharma <atri(dot)jiit(at)gmail(dot)com>, "Ben Zeev, Lior" <lior(dot)ben-zeev(at)hp(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: PostgreSQL Process memory architecture
Date: 2013-05-28 15:15:17
Message-ID: CAHyXU0zhYLJc2jgQs1_YjtqfoZmjm+5sOvNbV9H+2vmtyBR0Jw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, May 27, 2013 at 7:29 AM, Stephen Frost <sfrost(at)snowman(dot)net> wrote:
> * Atri Sharma (atri(dot)jiit(at)gmail(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2013-05-28 15:21:05 Re: fallocate / posix_fallocate for new WAL file creation (etc...)
Previous Message Jon Nelson 2013-05-28 15:12:05 Re: fallocate / posix_fallocate for new WAL file creation (etc...)