Martijn van Oosterhout writes:
> If you do a \d, does that load every tuple from pg_class into the
> catcache?
Many of 'em, not sure about "all".
regards, tom lane
---(end of broadcast)---
TIP 3: Have you checked our extens
On Wed, Jun 14, 2006 at 08:04:31PM -0400, Tom Lane wrote:
> So I'm pretty strongly inclined to just dike out the limit. If you're
> running a database big enough to hit the existing limit, you can well
> afford to put more memory into the catcache.
If you do a \d, does that load every tuple from
Tom Lane wrote:
> Bruce Momjian writes:
> > Tom Lane wrote:
> >> I just thought of a more radical idea: do we need a limit on catcache
> >> size at all? On "normal size" databases I believe that we never hit
> >> 5000 entries at all (at least, last time I ran the CATCACHE_STATS code
> >> on the r
Bruce Momjian writes:
> Tom Lane wrote:
>> I just thought of a more radical idea: do we need a limit on catcache
>> size at all? On "normal size" databases I believe that we never hit
>> 5000 entries at all (at least, last time I ran the CATCACHE_STATS code
>> on the regression tests, we didn't g
Tom Lane wrote:
> Bruce Momjian writes:
> > I am thinking we should scale it based on max_fsm_relations.
>
> Hmm ... tables are not the only factor in the required catcache size,
> and max_fsm_relations tells more about the total installation size
> than the number of tables in your particular da
Bruce Momjian writes:
> I am thinking we should scale it based on max_fsm_relations.
Hmm ... tables are not the only factor in the required catcache size,
and max_fsm_relations tells more about the total installation size
than the number of tables in your particular database. But it's one
possib
I am thinking we should scale it based on max_fsm_relations.
---
Tom Lane wrote:
> Awhile back, there was a discussion about psql \d display being really
> slow in a database with 4000 tables:
> http://archives.postgresql.or
Awhile back, there was a discussion about psql \d display being really
slow in a database with 4000 tables:
http://archives.postgresql.org/pgsql-hackers/2005-09/msg01085.php
I looked into this some, and it seems that part of the problem is that
the catalog caches are limited to hold no more than 5
