Hello Amit,
[...]
The objective is to help avoid PG stalling when fsyncing on checkpoints,
and in general to get better latency-bound performance.
Won't this lead to more-unsorted writes (random I/O) as the
FlushBuffer requests (by checkpointer or bgwriter) are not sorted as
per files or order of blocks on disk?
Yep, probably. Under "moderate load" this is not an issue. The
io-scheduler and other hd firmware will probably reorder writes anyway.
Also, if several data are updated together, probably they are likely to be
already neighbours in memory as well as on disk.
I remember sometime back there was some discusion regarding
sorting writes during checkpoint, one idea could be try to
check this idea along with that patch. I just saw that Andres has
also given same suggestion which indicates that it is important
to see both the things together.
I would rather separate them, unless this is a blocker. This version seems
already quite effective and very light. ISTM that adding a sort phase
would mean reworking significantly how the checkpointer processes pages.
Also here another related point is that I think currently even fsync
requests are not in order of the files as they are stored on disk so
that also might cause random I/O?
I think that currently the fsync is on the file handler, so what happens
depends on how fsync is implemented by the system.
Yet another idea could be to allow BGWriter to also fsync the dirty
buffers,
ISTM That it is done with this patch with "bgwriter_flush_to_disk=on".
that may have side impact of not able to clear the dirty pages at speed
required by system, but I think if that happens one can think of having
multiple BGwriter tasks.
--
Fabien.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
