> The problem can generally be written as "tuples seeing multiple
> updates in the same transaction"?
> I think that every time PostgreSQL is used with an ORM, there is
> a certain amount of multiple updates taking place. I have actually
> been reworking clientside to get around multiple updates, since they
> popped up in one of my profiling runs. Allthough the time I optimized
> away ended being both "roundtrip time" + "update time", but having
> the database do half of it transparently, might have been sufficient
> to get me to have had a bigger problem elsewhere..
> To sum up. Yes I think indeed it is a real-world case.
On the Python side, elixir and sqlalchemy have an excellent way of
handling this, basically when you start a transaction, all changes are
accumulated in a "session" object and only flushed to the database on
session commit (which is also generally the transaction commit). This has
multiple advantages, for instance it is able to issue multiple-line
statements, updates are only done once, you save a lot of roundtrips, etc.
Of course it is most of the time not compatible with database triggers, so
if there are triggers the ORM needs to be told about them.
In response to
pgsql-hackers by date
|Next:||From: Jesper Krogh||Date: 2010-07-05 10:26:23|
|Subject: Re: pessimal trivial-update performance|
|Previous:||From: Martin Pihlak||Date: 2010-07-05 09:58:09|
|Subject: Re: log files and permissions|