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
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...) |