>> 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.
