Re: [HACKERS] Performance issue in pg_dump's dependency loop searching

2014-07-29 Thread Simon Riggs
On 25 July 2014 20:47, Tom Lane t...@sss.pgh.pa.us wrote: Another idea would be to ...persist the optimal dump order in the database. That way we can maintain the correct dump order each time we do DDL, which is only a small incremental cost, no matter how many objects we have. -- Simon

Re: [HACKERS] Performance issue in pg_dump's dependency loop searching

2014-07-29 Thread Tom Lane
Simon Riggs si...@2ndquadrant.com writes: On 25 July 2014 20:47, Tom Lane t...@sss.pgh.pa.us wrote: Another idea would be to ...persist the optimal dump order in the database. That way we can maintain the correct dump order each time we do DDL, which is only a small incremental cost, no

Re: [HACKERS] Performance issue in pg_dump's dependency loop searching

2014-07-29 Thread Claudio Freire
On Tue, Jul 29, 2014 at 3:06 PM, Tom Lane t...@sss.pgh.pa.us wrote: Simon Riggs si...@2ndquadrant.com writes: On 25 July 2014 20:47, Tom Lane t...@sss.pgh.pa.us wrote: Another idea would be to ...persist the optimal dump order in the database. That way we can maintain the correct dump order

[HACKERS] Performance issue in pg_dump's dependency loop searching

2014-07-25 Thread Tom Lane
I looked into the performance issue Joe Van Dyk reported in bug #11033. It turns out this is basically a consequence of the section boundary pseudo-objects I added in commit a1ef01fe163b304760088e3e30eb22036910a495. (I'd worried about performance consequences at the time, but hadn't seen any