From: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> |
---|---|
To: | Cédric Villemain <cedric(at)2ndQuadrant(dot)com> |
Cc: | Andres Freund <andres(at)anarazel(dot)de>, PostgreSQL Developers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: checkpointer continuous flushing |
Date: | 2015-06-08 08:00:20 |
Message-ID: | alpine.DEB.2.10.1506080951480.5519@sto |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hello Cédric,
> It looks a bit hazardous, do you have a benchmark for freeBSD ?
No, I just consulted the FreeBSD man page for posix_fadvise. I someone can
run tests on something which HDDs is not linux, that would be nice.
> Sources says:
> case POSIX_FADV_DONTNEED:
> /*
> * Flush any open FS buffers and then remove pages
> * from the backing VM object. Using vinvalbuf() here
> * is a bit heavy-handed as it flushes all buffers for
> * the given vnode, not just the buffers covering the
> * requested range.
It is indeed heavy-handed, but that would probably trigger the expected
behavior which is to start writing to disk, so I would expect to see
benefits similar to those of "sync_file_range" on Linux.
Buffer writes from bgwriter & checkpointer are throttled, which reduces
the potential impact of a "heavy-handed" approach in the kernel.
Now if on some platforms the behavior is absurd, obviously it would be
better to turn the feature off on those.
Note that this is already used by pg in "initdb", but the impact would
probably be very small anyway.
--
Fabien.
From | Date | Subject | |
---|---|---|---|
Next Message | Julien Rouhaud | 2015-06-08 08:17:11 | Re: pg_stat_archiver issue with aborted archiver |
Previous Message | Cédric Villemain | 2015-06-08 07:45:06 | Re: checkpointer continuous flushing |