Re: [PATCH 10/16] Introduce the concept that wal has a 'origin' node

Поиск
Список
Период
Сортировка
От Simon Riggs
Тема Re: [PATCH 10/16] Introduce the concept that wal has a 'origin' node
Дата
Msg-id CA+U5nMKHLbm49TLABeN34m0dd7=EYOj++1WJ-zCYqMUe2HU_qg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [PATCH 10/16] Introduce the concept that wal has a 'origin' node  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On 20 June 2012 11:26, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> "Kevin Grittner" <Kevin.Grittner@wicourts.gov> writes:
>> Simon Riggs <simon@2ndQuadrant.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.

The tests were conducted with the additional field added, so your
prediction is not verified.

The additional fields do not bloat WAL records - they take up exactly
the same space as before.

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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Amit Kapila
Дата:
Сообщение: Re: Allow WAL information to recover corrupted pg_controldata
Следующее
От: Heikki Linnakangas
Дата:
Сообщение: Re: [PATCH 10/16] Introduce the concept that wal has a 'origin' node