Re: Review: Revise parallel pg_restore's scheduling heuristic - Mailing list pgsql-hackers

From Kevin Grittner
Subject Re: Review: Revise parallel pg_restore's scheduling heuristic
Date
Msg-id 4A7015720200002500028F39@gw.wicourts.gov
Whole thread Raw
In response to Re: Review: Revise parallel pg_restore's scheduling heuristic  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Review: Revise parallel pg_restore's scheduling heuristic  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Tom Lane <tgl@sss.pgh.pa.us> wrote: 
> Also, the followup to that message points out that the 8.4.0 code
> has a potential O(N^2) dependency on the total number of TOC items
> in the dump.  So it might be interesting to check the behavior with
> very large numbers of tables/indexes.
I've got 431 user tables with 578 indexes.  How high should I push
this?  Can I just create a bunch of randomly named empty tables with
primary keys to provoke this effect?
-Kevin


pgsql-hackers by date:

Previous
From: "Kevin Grittner"
Date:
Subject: Re: Review: Revise parallel pg_restore's scheduling heuristic
Next
From: pgsql@mohawksoft.com
Date:
Subject: Re: xpath not a good replacement for xpath_string