Re: checkpointer continuous flushing
От | Fabien COELHO |
---|---|
Тема | Re: checkpointer continuous flushing |
Дата | |
Msg-id | alpine.DEB.2.10.1506021647320.17822@sto обсуждение исходный текст |
Ответ на | Re: checkpointer continuous flushing (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: checkpointer continuous flushing
|
Список | pgsql-hackers |
>> 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.
В списке pgsql-hackers по дате отправления: