Feedback-ID: ia2694551:Fastmail
Date: Tue, 4 Jul 2023 13:23:58 +0200
From: Alvaro Herrera <alvherre@alvh.no-ip.org>
To: Soumyadeep Chakraborty <soumyadeep2007@gmail.com>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>,
	Ashwin Agrawal <ashwinstar@gmail.com>,
	Tomas Vondra <tomas.vondra@enterprisedb.com>
Subject: Re: brininsert optimization opportunity
Message-ID: <20230704112358.bkm6r3fxp275m4lu@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CAE-ML+9r2=aO1wwji1sBN9gvPz2xRAtFUGfnffpd0ZqyuzjamA@mail.gmail.com>
Archived-At: <https://www.postgresql.org/message-id/20230704112358.bkm6r3fxp275m4lu%40alvherre.pgsql>
Precedence: bulk

On 2023-Jul-03, Soumyadeep Chakraborty wrote:

> My colleague, Ashwin, pointed out to me that brininsert's per-tuple init
> of the revmap access struct can have non-trivial overhead.
> 
> Turns out he is right. We are saving 24 bytes of memory per-call for
> the access struct, and a bit on buffer/locking overhead, with the
> attached patch.

Hmm, yeah, I remember being bit bothered by this repeated
initialization.  Your patch looks reasonable to me.  I would set
bistate->bs_rmAccess to NULL in the cleanup callback, just to be sure.
Also, please add comments atop these two new functions, to explain what
they are.

Nice results.

-- 
Álvaro Herrera        Breisgau, Deutschland  —  https://www.EnterpriseDB.com/