| From: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
|---|---|
| To: | Soumyadeep Chakraborty <soumyadeep2007(at)gmail(dot)com> |
| Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Ashwin Agrawal <ashwinstar(at)gmail(dot)com>, Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com> |
| Subject: | Re: brininsert optimization opportunity |
| Date: | 2023-07-04 11:23:58 |
| Message-ID: | 20230704112358.bkm6r3fxp275m4lu@alvherre.pgsql |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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/
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Yuya Watari | 2023-07-04 11:24:08 | Re: Making empty Bitmapsets always be NULL |
| Previous Message | David Rowley | 2023-07-04 11:15:45 | Re: Incremental sort for access method with ordered scan support (amcanorderbyop) |