Re: pg_attribute, pg_class, pg_depend grow huge in count and sizewith multiple tenants. - Mailing list pgsql-performance

From Jeff Janes
Subject Re: pg_attribute, pg_class, pg_depend grow huge in count and sizewith multiple tenants.
Date
Msg-id CAMkU=1x8KN5n8EqWnX0A6f4YAEFpD2H78dM-1Z=ybFrmmTcvZA@mail.gmail.com
Whole thread Raw
In response to Re: pg_attribute, pg_class, pg_depend grow huge in count and sizewith multiple tenants.  (Avinash Kumar <avinash.vallarapu@gmail.com>)
List pgsql-performance
On Thu, May 7, 2020 at 5:17 PM Avinash Kumar <avinash.vallarapu@gmail.com> wrote:
Hi,

On Thu, May 7, 2020 at 6:08 PM Rory Campbell-Lange <rory@campbell-lange.net> wrote:
One of our clusters has well over 500 databases fronted by pg_bouncer.

We get excellent connection "flattening" using pg_bouncer with
per-database connection spikes dealt with through a reserve pool.
What if you see at least 4 connections being established by each client during peak ? And if you serve 4 or 2  connections per each DB, then you are creating 1000 or more reserved connections with 500 DBs in a cluster. 

Does every database spike at the same time?
 

The nice thing about separate databases is that it is easy to scale
horizontally.
Agreed. But, how about autovacuum ? Workers shift from DB to DB and 500 clusters means you may have to have a lot of manual vacuuming in place as well.

Why would having difference schemas in different DBs change your manual vacuuming needs?  And if anything, having separate DBs will make autovacuuming more efficient, as it keeps the statistics collectors stats files smaller.
 
Cheers,

Jeff

pgsql-performance by date:

Previous
From: Jeff Janes
Date:
Subject: Re: pg_attribute, pg_class, pg_depend grow huge in count and sizewith multiple tenants.
Next
From: Arya F
Date:
Subject: Re: 600 million rows of data. Bad hardware or need partitioning?