On Wed, Nov 14, 2012 at 12:04 PM, Jon Nelson <jnelson+pgsql@xxxxxxxxxxx> wrote: > On Wed, Nov 14, 2012 at 1:01 PM, Jeff Janes <jeff.janes@xxxxxxxxx> wrote: >> >> While the WAL is suppressed for the table inserts, it is not >> suppressed for the index inserts, and the index WAL traffic is enough >> to lead to contention. > > Aha! > >> I don't know why that is the case, it seems like the same method that >> allows us to bypass WAL for the table would work for the indices as >> well. Maybe it is just that no one bothered to implement it. After >> all, building the index after the copy will be even more efficient >> than building it before but by-passing WAL. > >> But it does seem like the docs could at least be clarified here. > > In general, then, would it be safe to say that concurrent (parallel) > index creation may be a source of significant WAL contention? No, that shouldn't lead to WAL contention. The creation of an index on an already-populated table bypasses most WAL when you are not using archiving. It is the maintenance of an already existing index that generates WAL. "begin; truncate; copy; create index" generates little WAL. "begin; truncate; create index; copy" generates a lot of WAL, and is slower for other reason as well. Cheers, Jeff -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
