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 base
On Fri, Oct 27, 2017 at 12:04 PM, Weiping Qu 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 an
That's a good point and we haven't accounted for disk caching.
Is there any way to confirm this fact in PostgreSQL?
Weiping
On 27.10.2017 11:53, Francisco Olarte wrote:
On Thu, Oct 26, 2017 at 10:20 PM, Weiping Qu wrote:
However, the plots showed different trend (currently I don't have plot
On Thu, Oct 26, 2017 at 10:20 PM, Weiping Qu wrote:
> However, the plots showed different trend (currently I don't have plots on
> my laptop) which shows that the more frequently are the CDC processes
> reading from logical slots, the less overhead is incurred over PostgreSQL,
> which leads to hi
Hi. Thank you very much for such detailed explanation. :)
We are currently testing the overhead of log-based Change Data Capture
method (i.e. logical decoding) over Postgresql.
The test setting consists of one processing running TPC-C on node1,
which issued transactions against a database residi
Hi. I've had experience with both BDR & pglogical. For each replication slot,
postgres saves a LSN which points to the last xlog entry read by the client.
When a client does not reads xlog, for example, if it cannot connect to the
server, then the distance between such LSN(pg_replication_slots.r
