Re: brininsert optimization opportunity

Поиск
Список
Период
Сортировка
От Alvaro Herrera
Тема Re: brininsert optimization opportunity
Дата
Msg-id 20230704112358.bkm6r3fxp275m4lu@alvherre.pgsql
обсуждение исходный текст
Ответ на brininsert optimization opportunity  (Soumyadeep Chakraborty <soumyadeep2007@gmail.com>)
Ответы Re: brininsert optimization opportunity  (Tomas Vondra <tomas.vondra@enterprisedb.com>)
Список 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/



В списке pgsql-hackers по дате отправления:

Предыдущее
От: David Rowley
Дата:
Сообщение: Re: Incremental sort for access method with ordered scan support (amcanorderbyop)
Следующее
От: Yuya Watari
Дата:
Сообщение: Re: Making empty Bitmapsets always be NULL