From: | "Ben Zeev, Lior" <lior(dot)ben-zeev(at)hp(dot)com> |
---|---|
To: | Stephen Frost <sfrost(at)snowman(dot)net> |
Cc: | Atri Sharma <atri(dot)jiit(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: PostgreSQL Process memory architecture |
Date: | 2013-05-27 13:30:45 |
Message-ID: | 59E5FDBE8F3B144F8FCF35819B39DD4C162431ED@G6W2498.americas.hpqcorp.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Great, Thanks !!!
I will try and let you update
-----Original Message-----
From: Stephen Frost [mailto:sfrost(at)snowman(dot)net]
Sent: Monday, May 27, 2013 16:29
To: Ben Zeev, Lior
Cc: Atri Sharma; Pg Hackers
Subject: Re: [HACKERS] PostgreSQL Process memory architecture
Lior,
* Ben Zeev, Lior (lior(dot)ben-zeev(at)hp(dot)com) wrote:
> Yes, The memory utilization per PostgreSQL backend process is when
> running queries against this tables, For example: select * from test where num=2 and c2='abc'
> When It start it doesn't consume to much memory, But as it execute
> against more and more indexes the memory consumption grows
It might be interesting, if possible for you, to recompile PG with -DCATCACHE_FORCE_RELEASE, which should cause PG to immediately release cached information when it's no longer being used. You'll be trading memory usage for CPU cycles, of course, but it might be better for your situation. We may still be able to do better than what we're doing today, but I'm still suspicious that you're going to run into other issues with having 500 indexes on a table anyway.
Thanks,
Stephen
From | Date | Subject | |
---|---|---|---|
Next Message | Stephen Frost | 2013-05-27 13:43:42 | Re: PostgreSQL Process memory architecture |
Previous Message | Stephen Frost | 2013-05-27 13:29:02 | Re: PostgreSQL Process memory architecture |