Re: improving concurrent transactin commit rate - Mailing list pgsql-hackers

From Tom Lane
Subject Re: improving concurrent transactin commit rate
Date
Msg-id 24562.1237994150@sss.pgh.pa.us
Whole thread Raw
In response to Re: improving concurrent transactin commit rate  (Greg Stark <stark@enterprisedb.com>)
List pgsql-hackers
Greg Stark <stark@enterprisedb.com> writes:
> What happens is that the first backend comes along, finds nobody else waiting
> and does an fsync for its own work. While that fsync is happening the rest of
> the crowd -- N-1 backends -- comes along and blocks waiting on the lock. The
> first backend to get the lock fsyncs the whole N-1 transactions. When it's
> done though the whole crowd finds the log already syncs and goes back to work.
> The first transaction to commit again finds nobody waiting and syncs alone
> again. rinse lather repeat.

Right.  The idea of the commit-delay stuff is to avoid that by letting
the first guy wait a little bit before starting to sync, but as
mentioned, we've never been able to get it to work real well.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: shut down pgsql-interfaces (was Re: Function C and INOUT parameters)
Next
From: Guillaume Smet
Date:
Subject: Re: New trigger option of pg_standby