From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andreas Karlsson <andreas@proxel.se>
cc: Babak Ghadiri <bbkghadiri6@gmail.com>, pgsql-hackers@lists.postgresql.org
Subject: Re: Parallelizing startup with many databases
In-reply-to: <eed28e65-d978-400d-ba6e-83cef0d2c6b7@proxel.se>
References: 
 <CAEkHFKSxYO7Ryv_UNNGSe88zosg0_Q_dop6hXN0oCoYK28EZtA@mail.gmail.com>
 <eed28e65-d978-400d-ba6e-83cef0d2c6b7@proxel.se>
Comments: In-reply-to Andreas Karlsson <andreas@proxel.se>
	message dated "Sat, 03 Jan 2026 00:38:10 +0100"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <290549.1767398547.1@sss.pgh.pa.us>
Date: Fri, 02 Jan 2026 19:02:27 -0500
Message-ID: <290550.1767398547@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/290550.1767398547%40sss.pgh.pa.us>
Precedence: bulk

Andreas Karlsson <andreas@proxel.se> writes:
> On 1/2/26 8:55 AM, Babak Ghadiri wrote:
>> In PostgreSQL 16, startup appears to initialize databases sequentially and
>> primarily uses a single CPU core. In clusters with a very large number of
>> databases (around 5,000 in our case), this results in noticeably long
>> startup times after restarts or crash recovery.

> Have you measured what is actually causing the slow startup? Without 
> knowing what is actually slow it is hard to say if threading would even 
> help.

"perf" results would likely be useful.

I tried creating 5000 databases here and didn't notice any particular
increase in server startup time (didn't try crash-recovery case).
So whatever this is is likely somewhat configuration- or
platform-dependent.

Having said that, 5000 databases sounds like an anti-pattern to
begin with.  You're paying for an additional copy of the system
catalogs for each one.

			regards, tom lane