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.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
