Thanks, Francisco. From the plots we got the same feeling, cache reads
with little lags and high cache hits really don't put extra burden on
the original write throughput for OLTP transactions. And log-based is
the most efficient and harm-less one as compared to trigger-based and
timestamp based change data capture.
Weiping
On 27.10.2017 14:03, Francisco Olarte wrote:
On Fri, Oct 27, 2017 at 12:04 PM, Weiping Qu <q...@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
