| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> |
| Cc: | "Simon Riggs" <simon(at)2ndquadrant(dot)com>, "Andres Freund" <andres(at)2ndquadrant(dot)com>, "Robert Haas" <robertmhaas(at)gmail(dot)com>, "Daniel Farina" <daniel(at)heroku(dot)com>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: [PATCH 10/16] Introduce the concept that wal has a 'origin' node |
| Date: | 2012-06-20 03:26:45 |
| Message-ID: | 14897.1340162805@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
"Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> writes:
> Simon Riggs <simon(at)2ndQuadrant(dot)com> wrote:
>> The proposal is to use WAL to generate the logical change stream.
>> That has been shown in testing to be around x4 faster than having
>> a separate change stream, which must also be WAL logged (as Jan
>> noted).
> Sure, that's why I want it.
I think this argument is basically circular. The reason it's 4x faster
is that the WAL stream doesn't actually contain all the information
needed to generate LCRs (thus all the angst about maintaining catalogs
in sync, what to do about unfriendly datatypes, etc). By the time the
dust has settled and you have a workable system, you will have bloated
WAL and given back a large chunk of that multiple, thereby invalidating
the design premise. Or at least that's my prediction.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Amit Kapila | 2012-06-20 03:40:53 | Re: Allow WAL information to recover corrupted pg_controldata |
| Previous Message | Robert Haas | 2012-06-20 03:06:20 | Re: performance regression in 9.2 when loading lots of small tables |