On Fri, Oct 27, 2017 at 12:04 PM, Weiping Qu <qu@informatik.uni-kl.de> wrote:
> That's a good point and we haven't accounted for disk caching.
> Is there any way to confirm this fact in PostgreSQL?
I doubt, as it names indicates cache should be hidden from the db server.
You could monitor the machine with varying lags and see the disk-cache
hit ratio , or monitor the throughput loss, a disk-cache effect should
exhibit a constant part for little lags, where you mostly do cache
reads, then a rising part as you begin reading from disks stabilizing
asyntotically ( as most of the fraction of reads comes from disk, but
it could also exhibit a jump if you are unlucky and you evict pages
you'll need soon ), but it is not a simple thing to measure, specially
with a job mix and long delays.
The xlog can do strange things. IIRC it is normally write-only ( only
used on crash recovery, to archive (ship) it and for log based
replication slots ), but postgres recycles segments ( which can have
an impact on big memory machines ). I do not know to what extent a
modern OS can detect the access pattern and do things like evict the
log pages early after sync.
Francisco Olarte.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general