Re: PG 15 (and to a smaller degree 14) regression due to ExprEvalStep size
От | David Rowley |
---|---|
Тема | Re: PG 15 (and to a smaller degree 14) regression due to ExprEvalStep size |
Дата | |
Msg-id | CAApHDvpjQ4UVNHp4YMPqg4CkSGbomeNWj7JzsYyQ1zCHb3kU4w@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: PG 15 (and to a smaller degree 14) regression due to ExprEvalStep size (Andres Freund <andres@anarazel.de>) |
Список | pgsql-hackers |
Thanks for looking at this. On Wed, 6 Jul 2022 at 12:32, Andres Freund <andres@anarazel.de> wrote: > > On 2022-06-29 11:40:45 +1200, David Rowley wrote: > > Another small thing which I considered doing was to put the > > hash_fcinfo_data field as the final field in > > ScalarArrayOpExprHashTable so that we could allocate the memory for > > the hash_fcinfo_data in the same allocation as the > > ScalarArrayOpExprHashTable. This would reduce the pointer > > dereferencing done in saop_element_hash() a bit further. I just > > didn't notice anywhere else where we do that for FunctionCallInfo, so > > I resisted doing this. > > I think that'd make sense - it does add a bit of size calculation magic, but > it shouldn't be a problem. I'm fairly sure we do this in other parts of the > code. I've now adjusted that. I also changed the hash_finfo field to make it so the FmgrInfo is inline rather than a pointer. This saves an additional dereference in saop_element_hash() and also saves a palloc(). I had to adjust the palloc for the ScalarArrayOpExprHashTable struct into a palloc0 due to the FmgrInfo being inlined. I considered just zeroing out the hash_finfo portion but thought it wasn't worth the extra code. > Are you good pushing this? I'm fine with you doing so wether you adapt it > further or not. Pushed. David
В списке pgsql-hackers по дате отправления: