Skip site navigation (1) Skip section navigation (2)

Re: [GENERAL] PostgreSQL backend process high memory usage issue

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Merlin Moncure <mmoncure(at)gmail(dot)com>
Cc: Shianmiin <Shianmiin(at)gmail(dot)com>, pgsql-general(at)postgresql(dot)org, pgsql-bugs <pgsql-bugs(at)postgresql(dot)org>
Subject: Re: [GENERAL] PostgreSQL backend process high memory usage issue
Date: 2011-04-13 05:29:43
Message-ID: 26138.1302672583@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-bugspgsql-general
Merlin Moncure <mmoncure(at)gmail(dot)com> writes:
> I think you may have uncovered a leak (I stand corrected).

> The number of schemas in your test is irrelevant -- the leak is
> happening in proportion to the number of views (set via \setrandom
> tidx 1 10).  At 1 I don't think it exists at all -- at 100 memory use
> grows very fast.

I don't think it's a leak, exactly: it's just that the "relcache" entry
for each one of these views occupies about 100K.  A backend that touches
N of the views is going to need about N*100K in relcache space.  I can't
get terribly excited about that.  Trying to reduce the size of the
relcache would be a net loss for most usage patterns (ie, we'd end up
increasing the amount of re-fetching from the system catalogs that
backends would have to do).  And I don't think that this test case has
much of anything to do with sane application design, anyway.  Do you
really need that many complex views?  Do you really need to have most
sessions touching all of them?

			regards, tom lane

In response to

Responses

pgsql-bugs by date

Next:From: Heikki LinnakangasDate: 2011-04-13 05:37:49
Subject: Re: BUG #5976: Corrupted pages on the production database
Previous:From: Vlad ArkhipovDate: 2011-04-13 03:52:07
Subject: BUG #5976: Corrupted pages on the production database

pgsql-general by date

Next:From: Tom LaneDate: 2011-04-13 05:44:58
Subject: Re: 9.0 Out of memory
Previous:From: Tom LaneDate: 2011-04-13 05:01:55
Subject: Re: 9.0 Out of memory

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group