Re: vacuum locking - Mailing list pgsql-performance

From Rob Nagler
Subject Re: vacuum locking
Date
Msg-id 16285.18127.773000.825179@gargle.gargle.HOWL
Whole thread Raw
In response to Re: vacuum locking  (Greg Stark <gsstark@mit.edu>)
List 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 by date:

Previous
From: Rob Nagler
Date:
Subject: Re: vacuum locking
Next
From: Tom Lane
Date:
Subject: Re: Use of multipart index with "IN"