Message-ID: <2b672382-c0b3-3f44-b72c-86b1077b082b@enterprisedb.com>
Date: Tue, 4 Jul 2023 13:59:21 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.12.0
Subject: Re: brininsert optimization opportunity
Content-Language: en-US
To: Alvaro Herrera <alvherre@alvh.no-ip.org>,
 Soumyadeep Chakraborty <soumyadeep2007@gmail.com>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>,
 Ashwin Agrawal <ashwinstar@gmail.com>
References: <20230704112358.bkm6r3fxp275m4lu@alvherre.pgsql>
From: Tomas Vondra <tomas.vondra@enterprisedb.com>
In-Reply-To: <20230704112358.bkm6r3fxp275m4lu@alvherre.pgsql>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Archived-At: 
 <https://www.postgresql.org/message-id/2b672382-c0b3-3f44-b72c-86b1077b082b%40enterprisedb.com>
Precedence: bulk


On 7/4/23 13:23, Alvaro Herrera wrote:
> 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.
> 

Yeah. I wonder how much of that runtime is the generate_series(),
though. What's the speedup if that part is subtracted. It's guaranteed
to be even more significant, but by how much?

regards

-- 
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company