Re: Slow Inserts on 1 table?

Поиск
Список
Период
Сортировка
От Martijn van Oosterhout
Тема Re: Slow Inserts on 1 table?
Дата
Msg-id 20050805092359.GC9171@svana.org
обсуждение исходный текст
Ответ на Re: Slow Inserts on 1 table?  (Gregory Youngblood <gsyoungblood@mac.com>)
Список pgsql-general
On Tue, Aug 02, 2005 at 10:55:22AM -0700, Gregory Youngblood wrote:
> Not to fan the flames, so to speak, but I do have on question. If
> this is a known limitation, I'd expect the behavior to be consistent.
> Instead, he is saying that the problem is intermittent. Sometimes it
> runs fine, other times it slows down to a snail's pace.
>
> So, does that mean the known problem is indeed intermittent, and not
> something that happens every time? Or, is this an issue that can be
> mostly eliminated with appropriate tuning?

The problem is basically that PostgreSQL chooses a seq scan if it
thinks the table is empty. But a normal CREATE TABLE fudges the
statistics so that it chooses an index scan.

The problem mostly arises if you use an ANALYZE or VACUUM ANALYZE
*after* you've deleted all the rows but *before* you load the data.
Don't do that. If you need to run VACUUM to clear out the table, do so,
just don't analyze at the same time. Or use TRUNCATE.

At least that's my experience.

Hope this helps,
--
Martijn van Oosterhout   <kleptog@svana.org>   http://svana.org/kleptog/
> Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a
> tool for doing 5% of the work and then sitting around waiting for someone
> else to do the other 95% so you can sue them.

Вложения

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

Предыдущее
От: go
Дата:
Сообщение: Re: Weird lock or bug maybe?
Следующее
От: Martijn van Oosterhout
Дата:
Сообщение: Re: renaming a table, and its primary key constraint