Re: checkpointer continuous flushing
От | Fabien COELHO |
---|---|
Тема | Re: checkpointer continuous flushing |
Дата | |
Msg-id | alpine.DEB.2.10.1506220926130.23011@sto обсуждение исходный текст |
Ответ на | Re: checkpointer continuous flushing (Jim Nasby <Jim.Nasby@BlueTreble.com>) |
Список | pgsql-hackers |
Hello Jim, >> The small problem I see is that for a very large setting there could be >> several seconds or even minutes of sorting, which may or may not be >> desirable, so having some control on that seems a good idea. > > ISTM a more elegant way to handle that would be to start off with a very > small number of buffers and sort larger and larger lists while the OS is busy > writing/syncing. You really have to have done a significant part/most/all of sorting before starting to write. >> Another argument is that Tom said he wanted that:-) > > Did he elaborate why? I don't see him on this thread (though I don't have all > of it). http://www.postgresql.org/message-id/6599.1409421040@sss.pgh.pa.us But it has more to do with memory management. >> In practice the value can be set at a high value so that it is nearly >> always sorted in one go. Maybe value "0" could be made special and used >> to trigger this behavior systematically, and be the default. > > It'd be nice if it was just self-tuning, with no GUC. Hmmm. It can easilly be turned into a boolean, but otherwise I have no clue about how to decide whether to sort and/or flush. > It looks like it'd be much better to get this committed without more than we > have now than to do without it though... Yep, I think the figures are definitely encouraging. -- Fabien.
В списке pgsql-hackers по дате отправления: