Re: split tablecmds.c - Mailing list pgsql-hackers

=?utf-8?Q?=C3=81lvaro?= Herrera <alvherre@kurilemu.de> writes:
> On 2025-Dec-01, Nathan Bossart wrote:
>> This file has over 22,000 lines and is too large to be included in GitHub's
>> code search results [0].  It appears to have been given its current form in
>> 2002 by commit 71dc300.  Previously, it was named command.c, which dates
>> 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/commands/tablecmds.c
-rw-rw-r--. 1 postgres postgres 183924 Jan 14  2014 REL8_0/src/backend/commands/tablecmds.c
-rw-rw-r--. 1 postgres postgres 195463 Jan 14  2014 REL8_1/src/backend/commands/tablecmds.c
-rw-rw-r--. 1 postgres postgres 211853 Jan 14  2014 REL8_2/src/backend/commands/tablecmds.c
-rw-rw-r--. 1 postgres postgres 207113 Aug 31  2013 REL8_3/src/backend/commands/tablecmds.c
-rw-rw-r--. 1 postgres postgres 240714 May  6  2014 REL8_4/src/backend/commands/tablecmds.c
-rw-rw-r--. 1 postgres postgres 250682 Aug  9  2014 REL9_0/src/backend/commands/tablecmds.c
-rw-rw-r--. 1 postgres postgres 294495 Dec 22  2015 REL9_1/src/backend/commands/tablecmds.c
-rw-rw-r--. 1 postgres postgres 325781 Aug  9  2017 REL9_2/src/backend/commands/tablecmds.c
-rw-rw-r--. 1 postgres postgres 329854 Oct  1  2018 REL9_3/src/backend/commands/tablecmds.c
-rw-rw-r--. 1 postgres postgres 355629 Feb  3  2020 REL9_4/src/backend/commands/tablecmds.c
-rw-rw-r--. 1 postgres postgres 379490 Jul 14  2020 REL9_5/src/backend/commands/tablecmds.c
-rw-rw-r--. 1 postgres postgres 380527 Jul 14  2020 REL9_6/src/backend/commands/tablecmds.c
-rw-rw-r--. 1 postgres postgres 437331 Jan  6  2022 REL_10/src/backend/commands/tablecmds.c
-rw-rw-r--. 1 postgres postgres 512821 Oct 16  2023 REL_11/src/backend/commands/tablecmds.c
-rw-rw-r--. 1 postgres postgres 559329 Nov  8  2024 REL_12/src/backend/commands/tablecmds.c
-rw-rw-r--. 1 postgres postgres 579305 Nov  4 10:59 REL_13/src/backend/commands/tablecmds.c
-rw-rw-r--. 1 postgres postgres 605939 Nov 10 12:43 REL_14/src/backend/commands/tablecmds.c
-rw-rw-r--. 1 postgres postgres 628963 Nov 10 12:43 REL_15/src/backend/commands/tablecmds.c
-rw-rw-r--. 1 postgres postgres 628950 Nov 10 12:43 REL_16/src/backend/commands/tablecmds.c
-rw-rw-r--. 1 postgres postgres 645181 Nov 10 12:43 REL_17/src/backend/commands/tablecmds.c
-rw-rw-r--. 1 postgres postgres 708183 Nov 10 12:43 REL_18/src/backend/commands/tablecmds.c
-rw-rw-r--. 1 postgres postgres 706254 Nov 10 12:43 HEAD/src/backend/commands/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