On 20 June 2012 00:11, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Andres Freund <andres@2ndquadrant.com> writes:
>> On Tuesday, June 19, 2012 04:30:59 PM Tom Lane wrote:
>>>> ... (If you are thinking
>>>> of something sufficiently high-level that merging could possibly work,
>>>> then it's not WAL, and we shouldn't be trying to make the WAL
>>>> representation cater for it.)
>
>> Do you really see this as such a big problem?
>
> It looks suspiciously like "I have a hammer, therefore every problem
> must be a nail". I don't like the design concept of cramming logical
> replication records into WAL in the first place.
The evidence from prototypes shown at PgCon was that using the WAL in
this way was very efficient and that this level of efficiency is
necessary to make it work in a practical manner. Postgres would not be
the first database to follow this broad design.
> However, if we're dead set on doing it that way, let us put information
> that is only relevant to logical replication records into only the
> logical replication records.
Agreed. In this case, the origin node id information needs to be
available on the WAL record so we can generate the logical changes
(LCRs).
> Saving a couple bytes in each such record
> is penny-wise and pound-foolish, I'm afraid; especially when you're
> nailing down hard, unexpansible limits at the very beginning of the
> development process in order to save those bytes.
Restricting the number of node ids is being done so that there is no
impact on anybody not using this feature.
In later implementations, it should be possible to support greater
numbers of node ids by having a variable length header. But that is an
unnecessary complication for a first release.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services