On Wed, Apr 13, 2011 at 12:29 AM, Tom Lane <tgl@xxxxxxxxxxxxx> wrote: > Merlin Moncure <mmoncure@xxxxxxxxx> 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 -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
