Re: postgres 8.4, COPY, and high concurrency

Поиск
Список
Период
Сортировка
От Jeff Janes
Тема Re: postgres 8.4, COPY, and high concurrency
Дата
Msg-id CAMkU=1wu72umecMkhwvA9ERbK5diFZ8ex5RbOatDWccF9Fp8iA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: postgres 8.4, COPY, and high concurrency  (Jon Nelson <jnelson+pgsql@jamponi.net>)
Ответы Re: postgres 8.4, COPY, and high concurrency  (Jon Nelson <jnelson+pgsql@jamponi.net>)
Список pgsql-performance
On Wed, Nov 14, 2012 at 6:41 AM, Jon Nelson <jnelson+pgsql@jamponi.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


В списке pgsql-performance по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: SOLVED - RE: Poor performance using CTE
Следующее
От: Jon Nelson
Дата:
Сообщение: Re: postgres 8.4, COPY, and high concurrency