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@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
