Re: A potential memory leak on Merge Join when Sort node is not below Materialize node
От | Tom Lane |
---|---|
Тема | Re: A potential memory leak on Merge Join when Sort node is not below Materialize node |
Дата | |
Msg-id | 65629.1664460603@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: A potential memory leak on Merge Join when Sort node is not below Materialize node (Ronan Dunklau <ronan.dunklau@aiven.io>) |
Ответы |
Re: A potential memory leak on Merge Join when Sort node is not below Materialize node
Re: A potential memory leak on Merge Join when Sort node is not below Materialize node |
Список | pgsql-hackers |
Ronan Dunklau <ronan.dunklau@aiven.io> writes: >> Yeah, I think the same rules around scope apply as >> tuplesort_gettupleslot() with copy==false. We could do it by adding a >> copy flag to the existing function, but I'd rather not add the >> branching to that function. It's probably just better to duplicate it >> and adjust. > For the record, I tried to see if gcc would optimize the function by > generating two different versions when copy is true or false, thus getting rid > of the branching while still having only one function to deal with. TBH, I think this is completely ridiculous over-optimization. There's exactly zero evidence that a second copy of the function would improve performance, or do anything but contribute to code bloat (which does have a distributed performance cost). regards, tom lane
В списке pgsql-hackers по дате отправления: