| From: | Andrei Lepikhov <a(dot)lepikhov(at)postgrespro(dot)ru> |
|---|---|
| To: | Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com>, vignesh C <vignesh21(at)gmail(dot)com> |
| Cc: | Amit Langote <amitlangote09(at)gmail(dot)com>, Richard Guo <guofenglinux(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Memory consumed by child SpecialJoinInfo in partitionwise join planning |
| Date: | 2024-02-14 04:19:59 |
| Message-ID: | 731d54ad-e412-40a7-995b-b0018f350e7d@postgrespro.ru |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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.
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.
--
regards,
Andrei Lepikhov
Postgres Professional
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Mark Dilger | 2024-02-14 04:34:20 | Re: BitmapHeapScan streaming read user and prelim refactoring |
| Previous Message | Zhijie Hou (Fujitsu) | 2024-02-14 04:03:58 | RE: Synchronizing slots from primary to standby |