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
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-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

Browse pgsql-bugs by date

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

Browse pgsql-general by date

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