Re: Postgres is not able to handle more than 4k tables!? - Mailing list pgsql-hackers

From Laurenz Albe
Subject Re: Postgres is not able to handle more than 4k tables!?
Date
Msg-id e36261772d03026c6adb24ea3c864ff267cbadcf.camel@cybertec.at
Whole thread Raw
In response to Re: Postgres is not able to handle more than 4k tables!?  (Stephen Frost <sfrost@snowman.net>)
List pgsql-hackers
On Thu, 2020-07-09 at 12:47 -0400, Stephen Frost wrote:
> I realize this is likely to go over like a lead balloon, but the churn
> in pg_class from updating reltuples/relpages has never seemed all that
> great to me when just about everything else is so rarely changed, and
> only through some user DDL action- and I agree that it seems like those
> particular columns are more 'statistics' type of info and less info
> about the definition of the relation.  Other columns that do get changed
> regularly are relfrozenxid and relminmxid.  I wonder if it's possible to
> move all of those elsewhere- perhaps some to the statistics tables as
> you seem to be alluding to, and the others to $somewhereelse that is
> dedicated to tracking that information which VACUUM is primarily
> concerned with.

Perhaps we could create pg_class with a fillfactor less than 100
so we het HOT updates there.
That would be less invasive.

Yours,
Laurenz Albe




pgsql-hackers by date:

Previous
From: Konstantin Knizhnik
Date:
Subject: Re: Postgres is not able to handle more than 4k tables!?
Next
From: Kasahara Tatsuhito
Date:
Subject: Re: Retry Cached Remote Connections for postgres_fdw in case remote backend gets killed/goes away