We just installed performance monitoring on our web application, and we're seeing a spiky pattern in response times from our Postgres 8.4 server. The spikes correspond with significant slowdown in our web app. The time seems to taken up largely in "Postgres commit":

Top database operations by time consumed

We're self-hosting Postgres 8.4.3 on Ubuntu 10.04, with essentially stock settings, on an Amazon EC2 c1.xlarge instance w/ EBS. Yes, I know that Postgres on EBS probably isn't the best setup. We plan to move to a newer Postgres DB on RDS later this year.

In the meantime, is there anything obvious that I should look at that might tame this spiky pattern?

1 Answer 1


It's hard to tell what exactly your graphs say. But commit is designed to be slow. By default, Postgres waits for changes to be written to disk before it lets commit return.

You can let commit complete before changes are written to disk with this option:

synchronous_commit = off

That should certainly help to spread the disk I/O required for commit over more time. The downside is that a server outage can cause completed transactions to be lost.

  • Ah, thank you, I think that helps me connect the dots. We have a large indexing job that runs every 15 minutes. It doesn't write, but it does entire-table queries on two tables that are occasionally written to. All that I/O contention would probably delay the WAL, right?
    – David Eyk
    Commented May 21, 2015 at 13:20
  • That is quite possible, but there are a lot of variables in play
    – Andomar
    Commented May 21, 2015 at 13:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.