Re: AdvanceXLInsertBuffer vs. WAL segment compressibility

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Chapman Flack <chap(at)anastigmatix(dot)net>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: AdvanceXLInsertBuffer vs. WAL segment compressibility
Date: 2016-07-26 20:21:45
Message-ID: CA+TgmoaJR3s6CymT2wa9L5QR0pKY0cBthfece8MtxaBADMXw0Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Jul 22, 2016 at 6:02 PM, Chapman Flack <chap(at)anastigmatix(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2016-07-26 20:33:06 Re: copyParamList
Previous Message Robert Haas 2016-07-26 20:11:50 Re: [sqlsmith] Failed assertion in joinrels.c