Re: Rapidly decaying performance repopulating a large table
От | David Wilson |
---|---|
Тема | Re: Rapidly decaying performance repopulating a large table |
Дата | |
Msg-id | e7f9235d0804221415o2b737d86oe6cee02862920840@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Rapidly decaying performance repopulating a large table ("Scott Marlowe" <scott.marlowe@gmail.com>) |
Ответы |
Re: Rapidly decaying performance repopulating a large table
Re: Rapidly decaying performance repopulating a large table |
Список | 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 по дате отправления: