Tom Lane <t...@sss.pgh.pa.us> wrote: > I think we've pretty much established that it doesn't make things > *worse*, so I'm sort of inclined to go ahead and apply it. The > theoretical advantage of eliminating O(N^2) search behavior seems > like reason enough, even if it takes a ridiculous number of tables > for that to become significant. Agreed, although I'm having some concerns about whether this should proceed based exclusively on my benchmarks. On a thread on the performance list, people are talking about restores which go several times faster with parallel restore (compared to a single job). On my hardware, I haven't even gotten it to run twice as fast. This means that parallel restore is not a good fit for servers like we have, at least with databases like we have, which means it's probably a poor environment to get benchmarks for this patch. :-( Can we get someone who has benchmarks showing parallel restore to be eight times the speed of a single job to benchmark with this patch, just for confirmation? -Kevin
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
