Re: poor performance when recreating constraints on large tables

Поиск
Список
Период
Сортировка
От Mike Broers
Тема Re: poor performance when recreating constraints on large tables
Дата
Msg-id BANLkTinBY9j=v_0Oc5-rVuKcaEuj9f4tYQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: poor performance when recreating constraints on large tables  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: poor performance when recreating constraints on large tables  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-performance
Thanks for the suggestion, maintenance_work_mem is set to the default of 16MB on the host that was taking over an hour as well as on the host that was taking less than 10 minutes.  I tried setting it to 1GB on the faster test server and it reduced the time from around 6-7 minutes to about 3:30.  this is a good start, if there are any other suggestions please let me know - is there any query to check estimated time remaining on long running transactions?



On Mon, Jun 6, 2011 at 3:37 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Mike Broers <mbroers@gmail.com> writes:
> I am in the process of implementing cascade on delete constraints
> retroactively on rather large tables so I can cleanly remove deprecated
> data.  The problem is recreating some foreign key constraints on tables of
> 55 million rows+ was taking much longer than the maintenance window I had,
> and now I am looking for tricks to speed up the process, hopefully there is
> something obvious i am overlooking.

maintenance_work_mem?

                       regards, tom lane

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

Предыдущее
От: Josh Berkus
Дата:
Сообщение: 8.4/9.0 simple query performance regression
Следующее
От: Tom Lane
Дата:
Сообщение: Re: 8.4/9.0 simple query performance regression