Re: Let PostgreSQL's On Schedule checkpoint write buffer smooth spread cycle by tuning IsCheckpointOnSchedule?

On 17/12/15 19:07, Robert Haas wrote:
> On Mon, Dec 14, 2015 at 6:08 PM, Tomas Vondra
> <tomas.vondra@2ndquadrant.com> wrote:
>> So we know that we should expect about
>>
>>    (prev_wal_bytes - wal_bytes) + (prev_wal_fpw_bytes - wal_fpw_bytes)
>>
>>    (       regular WAL        ) + (              FPW WAL             )
>>
>> to be produced until the end of the current checkpoint. I don't have a clear
>> idea how to transform this into the 'progress' yet, but I'm pretty sure
>> tracking the two types of WAL is a key to a better solution. The x^1.5 is
>> probably a step in the right direction, but I don't feel particularly
>> confident about the 1.5 (which is rather arbitrary).
>
> If it works well empirically, does it really matter that it's
> arbitrary?  I mean, the entire planner is full of fairly arbitrary
> assumptions about which things to consider in the cost model and which
> to ignore.  The proof that we have made good decisions there is in the
> query plans it generates.  (The proof that we have made bad decisions
> in some cases in the query plans, too.)

Agreed.

> I think a bigger problem for this patch is that Heikki seems to have
> almost completely disappeared.

Yeah, there's that problem too :-).

The reason I didn't commit this back then was lack of performance 
testing. I'm fairly confident that this would be a significant 
improvement for some workloads, and shouldn't hurt much even in the 
worst case. But I did only a little testing on my laptop. I think Simon 
was in favor of just committing it immediately, and Fabien wanted to see 
more performance testing before committing.

I was hoping that Digoal would re-ran his original test case, and report 
back on whether it helps. Fabien had a performance test setup, for 
testing another patch, but he didn't want to run it to test this patch. 
Amit did some testing, but didn't see a difference. We can take that as 
a positive sign - no regression - or as a negative sign, but I think 
that basically means that his test was just not sensitive to the FPW issue.

So Tomas, if you're willing to do some testing on this, that would be 
brilliant!

- Heikki