Re: Rapidly decaying performance repopulating a large table - Mailing list pgsql-general

From David Wilson
Subject Re: Rapidly decaying performance repopulating a large table
Date
Msg-id e7f9235d0804221415o2b737d86oe6cee02862920840@mail.gmail.com
Whole thread Raw
In response to Re: Rapidly decaying performance repopulating a large table  ("Scott Marlowe" <scott.marlowe@gmail.com>)
Responses Re: Rapidly decaying performance repopulating a large table  ("Scott Marlowe" <scott.marlowe@gmail.com>)
Re: Rapidly decaying performance repopulating a large table  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-general
On Tue, Apr 22, 2008 at 5:04 PM, Scott Marlowe <scott.marlowe@gmail.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.t.wilson@gmail.com

pgsql-general by date:

Previous
From: "Scott Marlowe"
Date:
Subject: Re: How to modify ENUM datatypes?
Next
From: "Scott Marlowe"
Date:
Subject: Re: Rapidly decaying performance repopulating a large table