Re: performance with triggers depends on table size?

Поиск
Список
Период
Сортировка
От Christian Mock
Тема Re: performance with triggers depends on table size?
Дата
Msg-id 20020815001710.GA23284@notemock.coretec.at
обсуждение исходный текст
Ответ на Re: performance with triggers depends on table size?  (Manfred Koizar <mkoi-pg@aon.at>)
Ответы Re: performance with triggers depends on table size?  (Manfred Koizar <mkoi-pg@aon.at>)
Список pgsql-general
On Wed, Aug 14, 2002 at 10:05:00PM +0200, Manfred Koizar wrote:

> 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

I see; thanks to you and Jochem for explaining.

> 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

There's a huge amount of clustering in the data, ATM I've got some 2 mio
rows in the output table and less than 1000 in the stats table; I don't
think they're inserted in equal chunks, but in the real database structure
there's some single-colum indexes on the event_stats table, e.g. on
the hour column, and data is inserted in chronological order.

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

So this means my kludgy solution is as good as it can get ATM? That
would mean going back to boring CGI script coding instead of fiddling
with performance :-/

Thanks a lot,

cm.

--
Christian Mock                          Wiedner Hauptstrasse 15
Senior Security Engineer                1040 Wien
CoreTEC IT Security Solutions GmbH      +43-1-5037273

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

Предыдущее
От: "Johnson, Shaunn"
Дата:
Сообщение: database tuning
Следующее
От: Tom Lane
Дата:
Сообщение: Re: database tuning