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

Re: Does RelCache/SysCache shrink except when relations are deleted?

From: "MauMau" <maumau307(at)gmail(dot)com>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Alvaro Herrera" <alvherre(at)commandprompt(dot)com>,"Merlin Moncure" <mmoncure(at)gmail(dot)com>,"Pg Hackers" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Does RelCache/SysCache shrink except when relations are deleted?
Date: 2011-09-29 15:05:36
Message-ID: 849BF81321BF4FAAAE0FAB25E2886BFC@maumau (view raw or flat)
Thread:
Lists: pgsql-hackers
From: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
> That's correct.  We used to have a limit on the size of catcache
> (if memory serves, it was something like 5000 entries).  We got rid of
> it after observing that performance fell off a cliff as soon as you had
> a working set larger than the cache limit.  Trust me, if we had a limit,
> you'd still be here complaining, the complaint would just take a
> different form ;-)

Yes, I can imagine. Now I'll believe that caching catalog entries in local 
memory without bound is one of PostgreSQL's elaborations for performance. 
64-bit computing makes that approach legit. Oracle avoids duplicate catalog 
entries by storing them in a shared memory, but that should necessate some 
kind of locking when accessing the shared catalog entries. PostgreSQL's 
approach, which does not require locking, is better for many-core 
environments.

> I concur with Merlin's advice to rethink your schema.  100000 tables is
> far beyond what any sane design could require, and is costing you on
> many levels (I'm sure the OS and filesystem aren't that happy with it
> either).

I agree. I'll suggest that to the customer, too. Thank you very much.

Regards
MauMau



In response to

pgsql-hackers by date

Next:From: Florian PflugDate: 2011-09-29 15:06:20
Subject: Re: Feature proposal: www_fdw
Previous:From: Tom LaneDate: 2011-09-29 14:45:00
Subject: Re: Does RelCache/SysCache shrink except when relations are deleted?

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