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

Re: Cost of opening and closing an empty transaction

From: "Albe Laurenz" <laurenz(dot)albe(at)wien(dot)gv(dot)at>
To: "Jon Leighton *EXTERN*" <j(at)jonathanleighton(dot)com>,<pgsql-performance(at)postgresql(dot)org>
Subject: Re: Cost of opening and closing an empty transaction
Date: 2012-09-24 09:48:23
Message-ID: D960CB61B694CF459DCFB4B0128514C20874B8A2@exadv11.host.magwien.gv.at (view raw or flat)
Thread:
Lists: pgsql-performance
Jon Leighton wrote:
> I'm one of the developers of the Ruby on Rails web framework.
> 
> In some situations, the framework generates an empty transaction
block.
> I.e. we sent a BEGIN and then later a COMMIT, with no other queries in
> the middle.
> 
> We currently can't avoid doing this, because a user *may* send queries
> inside the transaction.
> 
> I am considering the possibility of making the transaction lazy. So we
> would delay sending the BEGIN until we have the first query ready to
go.
> If that query never comes then neither BEGIN nor COMMIT would ever be
sent.
> 
> So my question is: is this a worthwhile optimisation to make? In
> particular, I am wondering whether empty transactions increase the
work
> the database has to do when there are several other connections open?
> I.e. does it cause contention?
> 
> If anyone has any insight about other database servers that would also
> be welcome.

The one thing that will be the same for all databases is that
saving the two client-server roud trips for BEGIN and COMMIT
is probably worth the effort if it happens often enough.

The question which resources an empty transaction consumes
is probably database specific; for PostgreSQL the expense is
not high, as far as I can tell.

Yours,
Laurenz Albe




In response to

Responses

pgsql-performance by date

Next:From: Kiriakos TsourapasDate: 2012-09-24 10:33:25
Subject: Postgres becoming slow, only full vacuum fixes it
Previous:From: Shiran KleidermanDate: 2012-09-24 06:45:06
Subject: Memory issues

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