On Wed, Feb 14, 2024 at 9:50 AM Andrei Lepikhov <a.lepik...@postgrespro.ru> wrote: > > On 30/1/2024 12:44, Ashutosh Bapat wrote: > > Thanks Vignesh. PFA patches rebased on the latest HEAD. The patch > > addressing Amit's comments is still a separate patch for him to > > review. > Thanks for this improvement. Working with partitions, I frequently see > peaks of memory consumption during planning. So, maybe one more case can > be resolved here. > Patch 0001 looks good. I'm not sure about free_child_sjinfo_members. Do > we really need it as a separate routine? It might be better to inline > this code.
try_partitionwise_join() is already 200 lines long. A separate function is better than adding more lines to try_partitionwise_join(). Also if someone wants to call build_child_join_sjinfo() outside try_partitionwise_join() may find free_child_sjinfo_members() handy. > Patch 0002 adds valuable comments, and I'm OK with that. > > Also, as I remember, some extensions, such as pg_hint_plan, call > build_child_join_sjinfo. It is OK to break the interface with a major > version. But what if they need child_sjinfo a bit longer and collect > links to this structure? I don't think it is a real stopper, but it is > worth additional analysis. If these extensions call build_child_join_sjinfo() and do not call free_child_sjinfo_members, they can keep their child sjinfo as long as they want. I didn't understand your concern. -- Best Wishes, Ashutosh Bapat
