Skip site navigation (1) Skip section navigation (2)

Re: Re: xReader, double-effort (was: Temporary tables under hot standby)

From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>
Cc: tgl(at)sss(dot)pgh(dot)pa(dot)us, andres(at)2ndquadrant(dot)com, aakash(dot)bits(at)gmail(dot)com, josh(at)postgresql(dot)org, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Re: xReader, double-effort (was: Temporary tables under hot standby)
Date: 2012-04-29 17:02:47
Message-ID: CA+U5nM+m2LG-pU91pK7PhpSzx=4rUNykYyMbndYo5_5gXBuV5g@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Sun, Apr 29, 2012 at 3:27 PM, Kevin Grittner
<Kevin(dot)Grittner(at)wicourts(dot)gov> wrote:

>> It would be enormously more performant for the master to be
>> emitting logical replication records to start with, since it
>> already has all the right names etc at hand at basically no cost.
>
> Not when the consumers are across a WAN, and that WAN is the biggest
> performance bottleneck and the most expensive resource involved.

I agree that the WAN is important, for both bandwidth and response time.

Though it isn't a given that logical change records (LCRs) will
require more bandwidth than physical WAL. WAL contains full page
images, index changes and other information that would be absent from
the LCR stream. It also depends upon the specification of the LCRs -
what metadata is included and whether the LCRs use text or binary.
Those choices have other impacts as well, so measurements and detailed
analysis is required to justify how to proceed. Which is what is in
progress now.

-- 
 Simon Riggs                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

In response to

pgsql-hackers by date

Next:From: Hannu KrosingDate: 2012-04-29 17:20:00
Subject: Re: Future In-Core Replication
Previous:From: Kevin GrittnerDate: 2012-04-29 16:54:30
Subject: Re: default_transaction_isolation = serializable causes crash under Hot Standby

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group