[prev in list] [next in list] [prev in thread] [next in thread] 

List:       pgsql-performance
Subject:    Re: [PERFORM] Cost of opening and closing an empty transaction
From:       "Albe Laurenz" <laurenz.albe () wien ! gv ! at>
Date:       2012-09-24 9:48:23
Message-ID: D960CB61B694CF459DCFB4B0128514C20874B8A2 () exadv11 ! host ! magwien ! gv ! at
[Download RAW message or body]

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




-- 
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
[prev in list] [next in list] [prev in thread] [next in thread]