From: Chapman Flack <chap@anastigmatix.net>
To: Michael Paquier <michael.paquier@gmail.com>
To: Heikki Linnakangas <hlinnaka@iki.fi>
Cc: Robert Haas <robertmhaas@gmail.com>
Cc: Bruce Momjian <bruce@momjian.us>
Cc: PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Subject: Re: AdvanceXLInsertBuffer vs. WAL segment compressibility
Date: Wed, 26 Jul 2017 23:05:24 -0400
Message-ID: <59795874.9020503@anastigmatix.net> (raw)
In-Reply-To: <CAB7nPqQr1D3gjx8CmHYQREidG2eeGHzx2yQ97B3t2L99GE=+kQ@mail.gmail.com>
References: <579297F8.7020107@anastigmatix.net>
<CA+TgmoaJR3s6CymT2wa9L5QR0pKY0cBthfece8MtxaBADMXw0Q@mail.gmail.com>
<5797D953.6040806@anastigmatix.net>
<20160802183347.GD32575@momjian.us>
<CA+TgmobKFW5eVx4gd9TyiXv9iL_5DcC0-6UuJLXvwG1Ft1Pn-g@mail.gmail.com>
<20943eba-bbb9-390c-01b1-e6704ce33c7b@iki.fi>
<594C9457.6000708@anastigmatix.net>
<59506148.1010708@anastigmatix.net>
<2b9ed9a4-56a6-a4db-0abf-3527d993e2d4@iki.fi>
<fe79f7c5-2bc5-f763-8908-78675ba33eba@anastigmatix.net>
<d190140f-b6e8-5e2f-c663-c8f9617da18e@iki.fi>
<CAB7nPqQr1D3gjx8CmHYQREidG2eeGHzx2yQ97B3t2L99GE=+kQ@mail.gmail.com>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>
On 07/17/17 11:29, Michael Paquier wrote:
> FWIW, I would rather see any optimization done in
> AdvanceXLInsertBuffer() instead of seeing a second memset re-zeroing
> the WAL page header after its data has been initialized by
> AdvanceXLInsertBuffer() once.
Is that an aesthetic 'rather', or is there a technical advantage you
have in mind?
I also began by looking at how to stop AdvanceXLInsertBuffer()
initializing headers and taking locks when neither is needed.
But Heikki's just-rezero-them suggestion has a definite simplicity
advantage. It can be implemented entirely with a tight group of
lines added to CopyXLogRecordToWAL, as opposed to modifying
AdvanceXLInsertBuffer in a few distinct places, adding a parameter,
and changing its call sites.
There's a technical appeal to making the changes in AdvanceXLInsertBuffer
(who wants to do unnecessary initialization and locking?), but the amount
of unnecessary work that can be avoided is proportional to the number of
unused pages at switch time, meaning it is largest when the system
is least busy, and may be of little practical concern.
Moreover, optimizing AdvanceXLInsertBuffer would reveal one more
complication: some of the empty pages about to be written out may
have been initialized opportunistically in earlier calls to
AdvanceXLInsertBuffer, so those already have populated headers, and
would need rezeroing anyway. And not necessarily just an insignificant
few of them: if XLOGChooseNumBuffers chose the maximum, it could even
be all of them.
That might also be handled by yet another conditional within
AdvanceXLInsertBuffer. But with all of that in view, maybe it is
just simpler to have one loop in CopyXLogRecordToWAL simply zero them all,
and leave AdvanceXLInsertBuffer alone, so no complexity is added when it
is called from other sites that are arguably hotter.
Zeroing SizeOfXLogShortPHD bytes doesn't cost a whole lot.
-Chap
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: chap@anastigmatix.net, michael.paquier@gmail.com, hlinnaka@iki.fi, robertmhaas@gmail.com, bruce@momjian.us
Subject: Re: AdvanceXLInsertBuffer vs. WAL segment compressibility
In-Reply-To: <59795874.9020503@anastigmatix.net>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox