On Wed, Apr 13, 2011 at 12:29 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Merlin Moncure <mmoncure@gmail.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?
Ya, my mistake -- it *felt* like a leak when of course it was not.
100k does seem like an awful lot though -- perhaps this could be
organized better? -- but that's not really the point. I've coded a
lot of multi schema designs and they tend to either go the one
session/schema route or the connection pooling route. Either way,
cache memory usage tends to work itself out pretty well (it's never
been a problem for me before at least). I can't recall anyone ever
even complaining about it in a non synthetic test.
merlin