Re: AdvanceXLInsertBuffer vs. WAL segment compressibility

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: AdvanceXLInsertBuffer vs. WAL segment compressibility
Дата
Msg-id CA+TgmoaJR3s6CymT2wa9L5QR0pKY0cBthfece8MtxaBADMXw0Q@mail.gmail.com
обсуждение исходный текст
Ответ на AdvanceXLInsertBuffer vs. WAL segment compressibility  (Chapman Flack <chap@anastigmatix.net>)
Ответы Re: AdvanceXLInsertBuffer vs. WAL segment compressibility  (Chapman Flack <chap@anastigmatix.net>)
Список pgsql-hackers
On Fri, Jul 22, 2016 at 6:02 PM, Chapman Flack <chap@anastigmatix.net> wrote:
> At $work, we have a usually-low-activity PG database, so that almost
> always the used fraction of each 16 MB WAL segment is far smaller
> than 16 MB, and so it's a big win for archived-WAL storage space
> if an archive-command can be written that compresses those files
> effectively.

I'm kind of curious WHY you are using archiving and forcing regular
segment switches rather than just using streaming replication.
Pre-9.0, use of archive_timeout was routine, since there was no other
way to ensure that the data ended up someplace other than your primary
with reasonable regularity.  But, AFAIK, streaming replication
essentially obsoleted that use case.  You can just dribble the
individual bytes over the wire a few at a time to the standby or, with
pg_receivexlog, to an archive location.  If it takes 6 months to fill
up a WAL segment, you don't care: you'll always have all the bytes
that were generated more than a fraction of a second before the master
melted into a heap of slag.

I'm not saying you don't have a good reason for doing what you are
doing, just that I cannot think of one.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: [sqlsmith] Failed assertion in joinrels.c
Следующее
От: Robert Haas
Дата:
Сообщение: Re: copyParamList