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
> 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
> If that query never comes then neither BEGIN nor COMMIT would ever be
> So my question is: is this a worthwhile optimisation to make? In
> particular, I am wondering whether empty transactions increase the
> 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.
In response to
pgsql-performance by date
|Next:||From: Kiriakos Tsourapas||Date: 2012-09-24 10:33:25|
|Subject: Postgres becoming slow, only full vacuum fixes it|
|Previous:||From: Shiran Kleiderman||Date: 2012-09-24 06:45:06|
|Subject: Memory issues|