From: | Mike Broers <mbroers(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: poor performance when recreating constraints on large tables |
Date: | 2011-06-06 22:10:30 |
Message-ID: | BANLkTinBY9j=v_0Oc5-rVuKcaEuj9f4tYQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Mike Broers <mbroers(at)gmail(dot)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
>
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2011-06-06 23:02:23 | Re: 8.4/9.0 simple query performance regression |
Previous Message | Josh Berkus | 2011-06-06 21:45:43 | 8.4/9.0 simple query performance regression |