On Tue, May 7, 2013 at 9:23 PM, Peter Geoghegan wrote:
> On Tue, May 7, 2013 at 12:48 PM, Jeff Janes wrote:
> > Anyway, I don't see this behavior change when turning on wal_debug and
> > looking in the logfiles for 'xlog flush request' messages.
>
> That could have everything to do with the hard
On Tue, May 7, 2013 at 12:48 PM, Jeff Janes wrote:
> Anyway, I don't see this behavior change when turning on wal_debug and
> looking in the logfiles for 'xlog flush request' messages.
That could have everything to do with the hardware you're using. In
general, the higher the cost of an fsync, th
> Are you sure you properly cleared out the stats between profiling sessions?
> Also, XLogFlush gets called by background processes like autovac,
> checkpointer and bgwriter, in addition to being called by committing
> processes. If one profiled session contained a checkpoint and other did
> not,
On Tue, May 7, 2013 at 7:52 PM, Amit Langote wrote:
> So, any rise in number of XLogFlush() calls should roughly
> be accounted for by increased throughput. Am I right in interpreting
> it this way?
I think so. There certainly isn't any question that the increased
throughput and the increased num
> 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
On Tue, May 7, 2013 at 2:20 AM, Amit Langote wrote:
> Hello,
>
> I have been trying to understand how group commit implementation works
> the way it does after 9.2 group commit enhancement patch
> (9b38d46d9f5517dab67dda1dd0459683fc9cda9f on REL9_2_STABLE). I admit
> it's a pretty old commit thoug
On Tue, May 7, 2013 at 8:13 AM, Amit Langote wrote:
> Profiling results show that XLogFlush() is called about twice as many
> times after this patch while for XLogWrite() count remains about same
> as before. This patch modifies XLogFlush() such that it offers the
> said performance gain by allev
Hello,
I have been trying to understand how group commit implementation works
the way it does after 9.2 group commit enhancement patch
(9b38d46d9f5517dab67dda1dd0459683fc9cda9f on REL9_2_STABLE). I have
observed some behavior in this regard that I could not understand.
Profiling results show that
Hello,
I have been trying to understand how group commit implementation works
the way it does after 9.2 group commit enhancement patch
(9b38d46d9f5517dab67dda1dd0459683fc9cda9f on REL9_2_STABLE). I admit
it's a pretty old commit though I seek some clarification as to how it
provides the performanc
On Fri, Aug 21, 2009 at 1:18 AM, Jeff Janes wrote:
> Maybe this is one of those things that is obvious when someone points
> it out to you, but right now I am not seeing it. If you look at the
> last eight lines of this snippet from XLogFlush, you see that if we
> obtain WriteRqstPtr under the W
On 21 August 2009 at 10:18 Jeff Janes wrote:
> The effect of this seems to be that when WALInsertLock is busy, group
> commits are suppressed.
Agreed, but its not a place to look at just yet since this is changing as part
of sync rep patch.
We do need to change this to make group commit work
Jeff Janes writes:
> Maybe this is one of those things that is obvious when someone points
> it out to you, but right now I am not seeing it. If you look at the
> last eight lines of this snippet from XLogFlush, you see that if we
> obtain WriteRqstPtr under the WALInsertLock, then we both write
Maybe this is one of those things that is obvious when someone points
it out to you, but right now I am not seeing it. If you look at the
last eight lines of this snippet from XLogFlush, you see that if we
obtain WriteRqstPtr under the WALInsertLock, then we both write and
flush up to the highest
13 matches
Mail list logo
