Re: Cost of opening and closing an empty transaction

From: Claudio Freire <klaussfreire(at)gmail(dot)com>
To: Jon Leighton <j(at)jonathanleighton(dot)com>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: Cost of opening and closing an empty transaction
Date: 2012-09-22 03:08:15
Message-ID: CAGTBQpaycMP6-9eNkrxs_T-EVb28EWBXmmuVrcE3oqNM4S0-Yw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On Fri, Sep 21, 2012 at 7:46 AM, Jon Leighton <j(at)jonathanleighton(dot)com> wrote:
> 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?

I found myself on a similar situation, with a different framework
(SQLAlchemy), and it turned out to be worthwhile, mainly because
regardless of the load generated on the database, which may or may not
be of consequence to a particular application, the very significant
saving of at least 4 roundtrips (send begin, receive ack, send commit,
receive ack) can be worth the effort.

In particular, my application had many and very likely such cases
where no query would be issued (because of caching), and we were able
to reduce overall latency from 20ms to 1ms. Presumably, the high
latencies were due to busy links since it was all on a private (but
very busy) network.

Now, from the point of view of what resources would this idle
transaction consume on the server, you will at least consume a
connection (and hold a worker process idle for no reason). If you want
high concurrency, you don't want to take a connection from the
connection pool unless you're going to use it, because you'll be
blocking other clients.

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Daniel Farina 2012-09-22 05:50:25 Re: Newbie performance problem - semop taking most of time ?
Previous Message Claudio Freire 2012-09-22 02:43:49 Re: PostgreSQL performance on 64 bit as compared to 32 bit