Re: postgres 8.4, COPY, and high concurrency

From: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
To: Jon Nelson <jnelson+pgsql(at)jamponi(dot)net>
Cc: Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org>
Subject: Re: postgres 8.4, COPY, and high concurrency
Date: 2012-11-14 19:01:57
Message-ID: CAMkU=1wu72umecMkhwvA9ERbK5diFZ8ex5RbOatDWccF9Fp8iA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On Wed, Nov 14, 2012 at 6:41 AM, Jon Nelson <jnelson+pgsql(at)jamponi(dot)net> wrote:
>
> UPDATE: I have been able to replicate the issue. The parent table (the
> one referenced in the LIKE portion of the CREATE TABLE statement) had
> three indices.
>
> Now that I've been able to replicate the issue, are there tests that I
> can perform that would be useful to people?
> I will also try to build a stand-alone test.

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.

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.

Cheers,

Jeff

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Jon Nelson 2012-11-14 20:04:12 Re: postgres 8.4, COPY, and high concurrency
Previous Message Tom Lane 2012-11-14 16:29:03 Re: SOLVED - RE: Poor performance using CTE