• T
    Fix O(N^2) behavior in pg_dump when many objects are in dependency loops. · b1be1294
    Tom Lane 提交于
    Combining the loop workspace with the record of already-processed objects
    might have been a cute trick, but it behaves horridly if there are many
    dependency loops to repair: the time spent in the first step of findLoop()
    grows as O(N^2).  Instead use a separate flag array indexed by dump ID,
    which we can check in constant time.  The length of the workspace array
    is now never more than the actual length of a dependency chain, which
    should be reasonably short in all cases of practical interest.  The code
    is noticeably easier to understand this way, too.
    
    Per gripe from Mike Roest.  Since this is a longstanding performance bug,
    backpatch to all supported versions.
    b1be1294
pg_dump_sort.c 31.4 KB