Re: brininsert optimization opportunity
От | Tomas Vondra |
---|---|
Тема | Re: brininsert optimization opportunity |
Дата | |
Msg-id | 2b672382-c0b3-3f44-b72c-86b1077b082b@enterprisedb.com обсуждение исходный текст |
Ответ на | Re: brininsert optimization opportunity (Alvaro Herrera <alvherre@alvh.no-ip.org>) |
Ответы |
Re: brininsert optimization opportunity
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: