Tom Lane b1be1294cc Fix O(N^2) behavior in pg_dump when many objects are in dependency loops. ... 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.		2012-03-31 15:51:27 -04:00
..
initdb	Translation updates	2012-02-23 20:28:42 +02:00
ipcclean	Some more gitignore cleanups: cover contrib and PL regression test outputs.	2010-09-22 17:23:05 -04:00
pg_config	Translation updates	2012-02-23 20:28:42 +02:00
pg_controldata	Translation updates	2012-02-23 20:28:42 +02:00
pg_ctl	Translation updates	2012-02-23 20:28:42 +02:00
pg_dump	Fix O(N^2) behavior in pg_dump when many objects are in dependency loops.	2012-03-31 15:51:27 -04:00
pg_resetxlog	Translation updates	2012-02-23 20:28:42 +02:00
pgevent	Update copyrights in source tree to 2008.	2008-01-01 19:46:01 +00:00
psql	Translation updates	2012-02-23 20:28:42 +02:00
scripts	Translation updates	2012-02-23 20:28:42 +02:00
Makefile	Update copyrights in source tree to 2008.	2008-01-01 19:46:01 +00:00