Re: XLogFlush invoked about twice as many times after 9.2 group commit enhancement - Mailing list pgsql-hackers

From Amit Langote
Subject Re: XLogFlush invoked about twice as many times after 9.2 group commit enhancement
Date
Msg-id CA+HiwqGSXYyXRx7mrkAOY5zx4L2tN=+wEwfHXoz7ffdc495aVA@mail.gmail.com
Whole thread Raw
In response to Re: XLogFlush invoked about twice as many times after 9.2 group commit enhancement  (Peter Geoghegan <pg@heroku.com>)
Responses Re: XLogFlush invoked about twice as many times after 9.2 group commit enhancement  (Peter Geoghegan <pg@heroku.com>)
List pgsql-hackers
> Why is that surprising? Most of those XLogFlush() calls will recheck
> the flushed-up-to point, and realize that another backend assumed the
> role of group commit leader, and flushed their WAL for them, so aside
> from the wait, the call to XLogFlush is cheap for that individual
> backend. It's being invoked twice as many times because backends *can*
> invoke it twice as many times.

After going through it again, I think, I am getting convinced it is
not surprising. Since, backends are now able to return quickly from
XLogFlush(), on an average, they should also be able to proceed to
next transactions faster and hence cause XLogFlush() to be invoked
more often. So, any rise in number of XLogFlush() calls should roughly
be accounted for by increased throughput. Am I right in interpreting
it this way?

--

Amit Langote



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: local_preload_libraries logspam
Next
From: Alvaro Herrera
Date:
Subject: Re: Make targets of doc links used by phpPgAdmin static