Re: checkpointer continuous flushing

>> Hmmm. I think it should be implemented as Tom suggested, that is per chunks
>> of shared buffers, in order to avoid allocating a "large" memory.
>
> I don't necessarily agree. But that's really just a minor implementation
> detail.

Probably.

> The actual problem is sorting & fsyncing in a way that deals efficiently
> with tablespaces, i.e. doesn't write to tablespaces one-by-one.
> Not impossible, but it requires some thought.

Hmmm... I would have neglected this point in a first approximation,
but I agree that not interleaving tablespaces could indeed loose some
performance.

>> ISTM that the two aspects are orthogonal, which would suggests two gucs
>> anyway.
>
> They're pretty closely linked from their performance impact.

Sure.

> IMO this feature, if done correctly, should result in better performance
> in 95+% of the workloads

To demonstrate that would require time...

> and be enabled by default.

I did not had such an ambition with the submitted patch:-)

> And that'll not be possible without actually writing mostly
> sequentially.

> It's also not just the sequential writes making this important, it's
> also that it allows to do the final fsync() of the individual segments
> as soon as their last buffer has been written out.

Hmmm... I'm not sure this would have a large impact. The writes are
throttled as much as possible, so fsync will catch plenty other writes
anyway, if there are some.

--
Fabien.