Skip site navigation (1) Skip section navigation (2)

Re: pessimal trivial-update performance

From: Andres Freund <andres(at)anarazel(dot)de>
To: pgsql-hackers(at)postgresql(dot)org
Cc: "Pierre C" <lists(at)peufeu(dot)com>, "Jesper Krogh" <jesper(at)krogh(dot)cc>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Robert Haas" <robertmhaas(at)gmail(dot)com>
Subject: Re: pessimal trivial-update performance
Date: 2010-07-05 10:28:38
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Monday 05 July 2010 12:11:38 Pierre C wrote:
> > 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.
> > 
> > Jesper
> 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.
Its also not concurrency safe in many cases.


In response to

pgsql-hackers by date

Next:From: Greg SmithDate: 2010-07-05 14:05:38
Subject: Re: Table partitioning - is anything coming?
Previous:From: Jesper KroghDate: 2010-07-05 10:26:23
Subject: Re: pessimal trivial-update performance

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group