Re: performance with triggers depends on table size?

Поиск
Список
Период
Сортировка
От Manfred Koizar
Тема Re: performance with triggers depends on table size?
Дата
Msg-id vpcllucv5ka7gp1keg4jmqc6rpbf4i6964@4ax.com
обсуждение исходный текст
Ответ на Re: performance with triggers depends on table size?  (Christian Mock <cm@coretec.at>)
Ответы Re: performance with triggers depends on table size?  (Christian Mock <cm@coretec.at>)
Список pgsql-general
On Wed, 14 Aug 2002 19:53:19 +0200, Christian Mock <cm@coretec.at>
wrote:
>Where's the big number of "Deleted" tuples coming from?

From repeatedly
>   UPDATE event_stats SET count = count + x_count
>    WHERE stat_id = result.stat_id;

Due to MVCC Postgres treats an UPDATE much like a DELETE and an
INSERT.  I suspect the deleted tuples get in the way, when the UNIQUE
constraint is checked.  This explains the linear increase of time per
tuple.  I guess you are inserting sorted by (c1, c2, c3) - or at least
in large chunks of equal (c1, c2, c3) -  and the "drops" in your
diagram occur whenever (c1, c2, c3) - or whatever the unique columns
on event_stats are - changes.

For now you have already found a solution/workaround.  In 7.3 this can
be expected to work better.

Servus
 Manfred

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

Предыдущее
От: Alex Rice
Дата:
Сообщение: Perl modules problem on OS X
Следующее
От: Tom Jenkins
Дата:
Сообщение: PG 7.2.1 core dump