Re: checkpointer continuous flushing
От | Fabien COELHO |
---|---|
Тема | Re: checkpointer continuous flushing |
Дата | |
Msg-id | alpine.DEB.2.10.1506030726380.20439@sto обсуждение исходный текст |
Ответ на | Re: checkpointer continuous flushing (Andres Freund <andres@anarazel.de>) |
Список | pgsql-hackers |
>>> That might be the case in a database with a single small table; i.e. >>> where all the writes go to a single file. But as soon as you have >>> large tables (i.e. many segments) or multiple tables, a significant >>> part of the writes issued independently from checkpointing will be >>> outside the processing of the individual segment. >> >> Statistically, I think that it would reduce the number of unrelated writes >> taken in a fsync by about half: the last table to be written on a >> tablespace, at the end of the checkpoint, will have accumulated >> checkpoint-unrelated writes (bgwriter, whatever) from the whole checkpoint >> time, while the first table will have avoided most of them. > > That's disregarding that a buffer written out by a backend starts to get > written out by the kernel after ~5-30s, even without a fsync triggering > it. I meant my argument with "continuous flushing" activated, so there is no up to 30 seconds delay induced my the memory manager. Hmmm, maybe I do not understood your argument. -- Fabien.
В списке pgsql-hackers по дате отправления: