Re: Statistics Import and Export
От | Andres Freund |
---|---|
Тема | Re: Statistics Import and Export |
Дата | |
Msg-id | zxpxlpaamrjdug6pk4z524ow7ddzvkoprrmx3yxprimvmuqdsa@tjsm77gfwr4l обсуждение исходный текст |
Ответ на | Re: Statistics Import and Export (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
Hi, On 2025-03-06 14:47:08 -0500, Tom Lane wrote: > Nathan Bossart <nathandbossart@gmail.com> writes: > > On Thu, Mar 06, 2025 at 01:47:34PM -0500, Tom Lane wrote: > >> ... I wonder if we could just rip out pg_upgrade's support > >> for DB-level parallelism, which is not terribly pretty anyway, and > >> simply pass the -j switch straight to pg_dump and pg_restore. > > > That would certainly help for clusters with one big database with many LOs > > or something, but I worry it would hurt the many database case quite a bit. > > I'm very skeptical of that. How many DBs do you know with just one table? > I think most have enough that they could keep a reasonable number of > CPUs busy with pg_dump's internal parallelism. pg_dump as used by pg_upgrade doesn't need to dump table data. Afaict we only do parallelism in pg_dump for table data and large objects. Outside of the many-LOs case, there's nothing pg_dump's internal parallelism can accelerate? So the number of tables in a database is irrelevant, no? Greetings, Andres Freund
В списке pgsql-hackers по дате отправления: