Re: Huge memory consumption on partitioned table with FKs
Amit Langote <amitlangote09@gmail.com>
From: Amit Langote <amitlangote09@gmail.com>
To: Andy Fan <zhihui.fan1213@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Kyotaro Horiguchi <horikyota.ntt@gmail.com>, keisuke kuroda <keisuke.kuroda.3862@gmail.com>,
Alvaro Herrera <alvherre@alvh.no-ip.org>, Tatsuro Yamada <tatsuro.yamada.tf@nttcom.co.jp>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>,
tatsuhito.kasahara.rd@hco.ntt.co.jp
Date: 2021-03-08T12:58:03Z
Lists: pgsql-hackers
On Mon, Mar 8, 2021 at 9:53 PM Andy Fan <zhihui.fan1213@gmail.com> wrote: > On Mon, Mar 8, 2021 at 8:42 PM Amit Langote <amitlangote09@gmail.com> wrote: >> On Mon, Mar 8, 2021 at 8:39 PM Andy Fan <zhihui.fan1213@gmail.com> wrote: >> > On Mon, Mar 8, 2021 at 3:43 PM Andy Fan <zhihui.fan1213@gmail.com> wrote: >> >> My point below is a bit off-topic, but I want to share it here. Since >> >> we implement a partitioned table in PG with the inherited class, it has much >> >> more flexibility than other databases. Like in PG, we allow different partitions >> >> have different physical order, different indexes, maybe different index states. >> >> that would cause our development work hard in many places and cause some >> >> runtime issues as well (like catalog memory usage), have we discussed >> >> limiting some flexibility so that we can have better coding/running experience? >> >> I want to do some research in this direction, but it would be better that I can >> >> listen to any advice from others. More specifically, I want to reduce the memory >> >> usage of Partitioned table/index as the first step. In my testing, each IndexOptInfo >> >> will use 2kB memory in each backend. >> > >> > >> > As for the compatible issue, will it be ok to introduce a new concept like " >> > CREATE TABLE p (a int) partitioned by list(a) RESTRICTED". We can add these >> > limitation to restricted partitioned relation only. >> >> I think you'd agree that the topics you want to discuss deserve a >> separate discussion thread. You may refer to this discussion in that >> new thread if you think that your proposals can solve the problem >> being discussed here more generally, which would of course be great. > > Sure, I can prepare more data and start a new thread for this. Great, thanks. -- Amit Langote EDB: http://www.enterprisedb.com
Commits
-
Avoid creating duplicate cached plans for inherited FK constraints.
- c3ffe3486368 14.0 landed