Re: Rapidly decaying performance repopulating a large table

From: "David Wilson" <david(dot)t(dot)wilson(at)gmail(dot)com>
To: "Scott Marlowe" <scott(dot)marlowe(at)gmail(dot)com>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: Rapidly decaying performance repopulating a large table
Date: 2008-04-22 21:15:11
Message-ID: e7f9235d0804221415o2b737d86oe6cee02862920840@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Tue, Apr 22, 2008 at 5:04 PM, Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com> wrote:
> Normally, after the first 50,000 or so the plan won't likely change
> due to a new analyze, so you could probably just analyze after 50k or
> so and get the same performance. If the problem is a bad plan for the
> inserts / copies.
>
> also, non-indexed foreign keyed fields can cause this problem.
>

Analyzing after the first 50k or so is easy enough, then; thanks for
the suggestion.

Foreign keys are definitely indexed (actually referencing a set of
columns that the foreign table is UNIQUE on).

Any other suggestions? COPY times alone are pretty much quadrupling my
table-rebuild runtime, and I can interrupt the current rebuild to try
things pretty much at a whim (nothing else uses the DB while a rebuild
is happening), so I'm pretty much game to try any reasonable
suggestions anyone has.

--
- David T. Wilson
david(dot)t(dot)wilson(at)gmail(dot)com

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Scott Marlowe 2008-04-22 21:18:47 Re: Rapidly decaying performance repopulating a large table
Previous Message Scott Marlowe 2008-04-22 21:14:14 Re: How to modify ENUM datatypes?