Re: checkpointer continuous flushing - Mailing list pgsql-hackers

From Andres Freund
Subject Re: checkpointer continuous flushing
Date
Msg-id 20160112122212.ioyds3tun3t3mpbe@alap3.anarazel.de
Whole thread Raw
In response to Re: checkpointer continuous flushing  (Amit Kapila <amit.kapila16@gmail.com>)
Responses Re: checkpointer continuous flushing  (Amit Kapila <amit.kapila16@gmail.com>)
List pgsql-hackers
On 2016-01-12 17:50:36 +0530, Amit Kapila wrote:
> On Tue, Jan 12, 2016 at 12:57 AM, Andres Freund <andres@anarazel.de> wrote:>
> >
> > My theory is that this happens due to the sorting: pgbench is an update
> > heavy workload, the first few pages are always going to be used if
> > there's free space as freespacemap.c essentially prefers those. Due to
> > the sorting all a relation's early pages are going to be in "in a row".
> >
> 
> Not sure, what is best way to tackle this problem, but I think one way could
> be to perform sorting at flush requests level rather than before writing
> to OS buffers.

I'm not following. If you just sort a couple hundred more or less random
buffers - which is what you get if you look in buf_id order through
shared_buffers - the likelihood of actually finding neighbouring writes
is pretty low.



pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: checkpointer continuous flushing
Next
From: Andres Freund
Date:
Subject: Allow to specify (auto-)vacuum cost limits relative to the database/cluster size?