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
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
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
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