Re: Huge memory consumption on partitioned table with FKs
От | Amit Langote |
---|---|
Тема | Re: Huge memory consumption on partitioned table with FKs |
Дата | |
Msg-id | CA+HiwqGrr2YOO6voBM6m_OAc9w-WMxe1gOuQ-UyDPin6zJtyZw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Huge memory consumption on partitioned table with FKs (Kyotaro Horiguchi <horikyota.ntt@gmail.com>) |
Список | pgsql-hackers |
On Fri, Dec 4, 2020 at 2:48 PM Kyotaro Horiguchi <horikyota.ntt@gmail.com> wrote: > At Fri, 4 Dec 2020 12:00:09 +0900, Keisuke Kuroda <keisuke.kuroda.3862@gmail.com> wrote in > > Hi Amit, > > > > > I have attached a patch in which I've tried to merge the ideas from > > > both my patch and Kuroda-san's. I liked that his patch added > > > conparentid to RI_ConstraintInfo because that saves a needless > > > syscache lookup for constraints that don't have a parent. I've kept > > > my idea to compute the root constraint id only once in > > > ri_LoadConstraint(), not on every invocation of ri_BuildQueryKey(). > > > Kuroda-san, anything you'd like to add to that? > > > > Thank you for the merge! It looks good to me. > > I think a fix for InvalidateConstraintCacheCallBack() is also good. > > > > I also confirmed that the patch passed the make check-world. > > It's fine that constraint_rood_id overrides constraint_id, but how > about that constraint_root_id stores constraint_id if it is not a > partition? That change makes the patch a bit simpler. My patch was like that before posting to this thread, but keeping constraint_id and constraint_root_id separate looked better for documenting the partitioning case as working differently from the regular table case. I guess a comment in ri_BuildQueryKey is enough for that though and it's not like we're using constraint_root_id in any other place to make matters confusing, so I changed it as you suggest. Updated patch attached. -- Amit Langote EDB: http://www.enterprisedb.com
Вложения
В списке pgsql-hackers по дате отправления: