Re: pg_upgrade --jobs

On 4/6/19 5:47 PM, senor wrote:
> Thanks Tom for the explanation. I assumed it was my ignorance of how the schema was handled that was making this look
likea problem that had already been solved and I was missing something.
 
> 
> I fully expected the "You're Doing It Wrong" part. That is out of my control but not beyond my influence.
> 
> I suspect I know the answer to this but have to ask. Using a simplified example where there are 100K sets of 4
tables,each representing the output of a single job, are there any shortcuts to upgrading that would circumvent
exportingthe entire schema? I'm sure a different DB design would be better but that's not what I'm working with.
 

An answer is going to depend on more information:

1) What is the time frame for moving from one version to another?
Both the setup and the actual downtime.

2) There are 500,000+ tables, but what is the amount of data involved?

3) Are all the tables active?

4) How are the tables distributed across databases in the cluster and 
schemas in each database?


> 
> Thanks
> 
> ________________________________________
> From: Ron <ronljohnsonjr@gmail.com>
> Sent: Saturday, April 6, 2019 4:57 PM
> To: pgsql-general@lists.postgresql.org
> Subject: Re: pg_upgrade --jobs
> 
> On 4/6/19 6:50 PM, Tom Lane wrote:
> 
> senor <frio_cervesa@hotmail.com><mailto:frio_cervesa@hotmail.com> writes:
> 
> 
> [snip]
> 
> The --link option to pg_upgrade would be so much more useful if it
> weren't still bound to serially dumping the schemas of half a million
> tables.
> 
> 
> 
> To be perfectly blunt, if you've got a database with half a million
> tables, You're Doing It Wrong.
> 
> Heavy (really heavy) partitioning?
> 
> --
> Angular momentum makes the world go 'round.
> 
> 
> 


-- 
Adrian Klaver
adrian.klaver@aklaver.com