Re: vacuum locking

Поиск
Список
Период
Сортировка
От Rob Nagler
Тема Re: vacuum locking
Дата
Msg-id 16285.18127.773000.825179@gargle.gargle.HOWL
обсуждение исходный текст
Ответ на Re: vacuum locking  (Greg Stark <gsstark@mit.edu>)
Список pgsql-performance
Greg Stark writes:
> I don't understand why you would expect overwriting to win here.
> What types of updates do you do on these tables?

These are statistics that we're adjusting.  I think that's pretty
normal stuff.  The DSS component is the avg() of these numbers on
particular groups.  The groups are related to foreign keys to
customers and other things.

> Normally I found using update on such a table was too awkward to
> contemplate so I just delete all the relation records that I'm
> replacing for the key I'm working with and insert new ones. This
> always works out to be cleaner code. In fact I usually leave such
> tables with no UPDATE grants on them.

In accounting apps, we do this, too.  It's awkward with all the
relationships to update all the records in the right order.  But
Oracle wins on delete/insert, too, because it reuses the tuples it
already has in memory, and it can reuse the same foreign key index
pages, too, since the values are usually the same.

The difference between Oracle and postgres seems to be optimism.
postgres assumes the transaction will fail and/or that a transaction
will modify lots of data that is used by other queries going on in
parallel.  Oracle assumes that the transaction is going to be
committed, and it might as well make the changes in place.

> In that situation I would have actually expected Postgres to do as well as or
> better than Oracle since that makes them both functionally
> equivalent.

I'll find out soon enough. :-)

Rob



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

Предыдущее
От: Rob Nagler
Дата:
Сообщение: Re: vacuum locking
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Use of multipart index with "IN"