Re: 7 hrs for a pg_restore?

Поиск
Список
Период
Сортировка
От Matthew
Тема Re: 7 hrs for a pg_restore?
Дата
Msg-id Pine.LNX.4.64.0802201811330.20402@aragorn.flymine.org
обсуждение исходный текст
Ответ на Re: 7 hrs for a pg_restore?  (Jeff Davis <pgsql@j-davis.com>)
Ответы Re: 7 hrs for a pg_restore?  (Jeff Davis <pgsql@j-davis.com>)
Re: 7 hrs for a pg_restore?  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-performance
On Wed, 20 Feb 2008, Jeff Davis wrote:
> However, building indexes in parallel would allow better CPU
> utilization.

We have a process here that dumps a large quantity of data into an empty
database, much like pg_restore, and then creates all the indexes at the
end. In order to speed up that bit, I initially made it spawn off several
threads, and make each thread run a CREATE INDEX operation in parallel.
However, this resulted in random errors from Postgres - something to do
with locked tables. So I changed it so that no two threads create indexes
for the same table at once, and that solved it.

Obviously creating several indexes for the same table in parallel is
better from a performance point of view, but you may have to fix that
error if you haven't already.

Matthew

--
for a in past present future; do
  for b in clients employers associates relatives neighbours pets; do
  echo "The opinions here in no way reflect the opinions of my $a $b."
done; done

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

Предыдущее
От: Jeff Davis
Дата:
Сообщение: Re: 7 hrs for a pg_restore?
Следующее
От: Jeff Davis
Дата:
Сообщение: Re: 7 hrs for a pg_restore?