Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vQ97D-00CVz0-1U for pgsql-hackers@arkaria.postgresql.org; Mon, 01 Dec 2025 18:59:15 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1vQ979-0040X1-35 for pgsql-hackers@arkaria.postgresql.org; Mon, 01 Dec 2025 18:59:12 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vQ979-0040Wt-2A for pgsql-hackers@lists.postgresql.org; Mon, 01 Dec 2025 18:59:11 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vQ977-002bSm-1w for pgsql-hackers@postgresql.org; Mon, 01 Dec 2025 18:59:11 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 5B1Ix1m5213386; Mon, 1 Dec 2025 13:59:02 -0500 From: Tom Lane To: =?utf-8?Q?=C3=81lvaro?= Herrera cc: Nathan Bossart , pgsql-hackers@postgresql.org Subject: Re: split tablecmds.c In-reply-to: <202512011754.hpa4uqkqtq4f@alvherre.pgsql> References: <202512011754.hpa4uqkqtq4f@alvherre.pgsql> Comments: In-reply-to =?utf-8?Q?=C3=81lvaro?= Herrera message dated "Mon, 01 Dec 2025 19:18:13 +0100" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <213384.1764615541.1@sss.pgh.pa.us> Content-Transfer-Encoding: quoted-printable Date: Mon, 01 Dec 2025 13:59:01 -0500 Message-ID: <213385.1764615541@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk =3D?utf-8?Q?=3DC3=3D81lvaro?=3D Herrera writes: > On 2025-Dec-01, Nathan Bossart wrote: >> This file has over 22,000 lines and is too large to be included in GitH= ub's >> code search results [0]. It appears to have been given its current for= m in >> 2002 by commit 71dc300. Previously, it was named command.c, which date= s >> back to the 80s. Is it time to split it into a few different files, >> similar to what was done to copy.c in 2020 by commit c532d15? > I think it makes sense. It's our largest source file at 690kB > the second being pg_dump.c (at 625kB) and also a candidate for > splitting. The third one, ruleutils.c, is slightly above half size, > 381kB! A lot of the bloat seems to be of recent vintage, too: $ ls -l REL*/src/backend/commands/tablecmds.c -rw-rw-r--. 1 postgres postgres 125011 Jan 14 2014 REL7_4/src/backend/com= mands/tablecmds.c -rw-rw-r--. 1 postgres postgres 183924 Jan 14 2014 REL8_0/src/backend/com= mands/tablecmds.c -rw-rw-r--. 1 postgres postgres 195463 Jan 14 2014 REL8_1/src/backend/com= mands/tablecmds.c -rw-rw-r--. 1 postgres postgres 211853 Jan 14 2014 REL8_2/src/backend/com= mands/tablecmds.c -rw-rw-r--. 1 postgres postgres 207113 Aug 31 2013 REL8_3/src/backend/com= mands/tablecmds.c -rw-rw-r--. 1 postgres postgres 240714 May 6 2014 REL8_4/src/backend/com= mands/tablecmds.c -rw-rw-r--. 1 postgres postgres 250682 Aug 9 2014 REL9_0/src/backend/com= mands/tablecmds.c -rw-rw-r--. 1 postgres postgres 294495 Dec 22 2015 REL9_1/src/backend/com= mands/tablecmds.c -rw-rw-r--. 1 postgres postgres 325781 Aug 9 2017 REL9_2/src/backend/com= mands/tablecmds.c -rw-rw-r--. 1 postgres postgres 329854 Oct 1 2018 REL9_3/src/backend/com= mands/tablecmds.c -rw-rw-r--. 1 postgres postgres 355629 Feb 3 2020 REL9_4/src/backend/com= mands/tablecmds.c -rw-rw-r--. 1 postgres postgres 379490 Jul 14 2020 REL9_5/src/backend/com= mands/tablecmds.c -rw-rw-r--. 1 postgres postgres 380527 Jul 14 2020 REL9_6/src/backend/com= mands/tablecmds.c -rw-rw-r--. 1 postgres postgres 437331 Jan 6 2022 REL_10/src/backend/com= mands/tablecmds.c -rw-rw-r--. 1 postgres postgres 512821 Oct 16 2023 REL_11/src/backend/com= mands/tablecmds.c -rw-rw-r--. 1 postgres postgres 559329 Nov 8 2024 REL_12/src/backend/com= mands/tablecmds.c -rw-rw-r--. 1 postgres postgres 579305 Nov 4 10:59 REL_13/src/backend/com= mands/tablecmds.c -rw-rw-r--. 1 postgres postgres 605939 Nov 10 12:43 REL_14/src/backend/com= mands/tablecmds.c -rw-rw-r--. 1 postgres postgres 628963 Nov 10 12:43 REL_15/src/backend/com= mands/tablecmds.c -rw-rw-r--. 1 postgres postgres 628950 Nov 10 12:43 REL_16/src/backend/com= mands/tablecmds.c -rw-rw-r--. 1 postgres postgres 645181 Nov 10 12:43 REL_17/src/backend/com= mands/tablecmds.c -rw-rw-r--. 1 postgres postgres 708183 Nov 10 12:43 REL_18/src/backend/com= mands/tablecmds.c -rw-rw-r--. 1 postgres postgres 706254 Nov 10 12:43 HEAD/src/backend/comma= nds/tablecmds.c I didn't do any math about it, but that's got to be a far faster rate of expansion than the overall PG code base. Maybe partitioning is largely to blame? Perhaps analyzing what functionality got added here in the past dozen or so years would yield some ideas for how to split it. +1 for a split, if we can figure out a good plan. regards, tom lane