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 <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
