Disable sequential scan on database tables in copy threads

This forces the DELETEs to use an index scan which is much faster.

The underlying problem here is probably that the DELETEs are called for
all OSM objects in the input file, regardless of whether they are even
in the table. For most tables most ids will not be in there. So
PostgreSQL overestimates the number of "hits" it is going to get and
thinks a full table scan is more efficient when in fact an index lookup
is much better.

The COPYs used in the same database connection are not affected by this.

In many tests I have done I only see this problem in some cases, but
when it hits it can slow down processing considerably. This could
explain the occasional slow processing that some people have been
reporting over the years and that we could never really nail down
(#1674, #1971).

Author: joto

src/db-copy.cpp

@@ -131,6 +131,14 @@ void db_copy_thread_t::thread_t::operator()()
         // Let commits happen faster by delaying when they actually occur.
         m_conn->exec("SET synchronous_commit = off");
 
+        // Disable sequential scan on database tables in the copy threads.
+        // The copy threads only do COPYs (which are unaffected by this
+        // setting) and DELETEs which we know benefit from the index. For
+        // some reason PostgreSQL chooses in some cases not to use that index,
+        // possibly because the DELETEs get a large list of ids to delete of
+        // which many are not in the table which confuses the query planner.
+        m_conn->exec("SET enable_seqscan = off");
+
         bool done = false;
         while (!done) {
             std::unique_ptr<db_cmd_t> item;