Re: [GENERAL] Question regarding logical replication
От | Francisco Olarte |
---|---|
Тема | Re: [GENERAL] Question regarding logical replication |
Дата | |
Msg-id | CA+bJJbyNw6BNAeVpXwYGy+D-Q21tALHCcYfD=B7qr5hSDuxECw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [GENERAL] Question regarding logical replication (Weiping Qu <qu@informatik.uni-kl.de>) |
Ответы |
Re: [GENERAL] Question regarding logical replication
|
Список | pgsql-general |
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
В списке pgsql-general по дате отправления: