My organization has a number of very large tables (most 100s of GB, a
couple over a Tb) that were created many years ago by a tool that
defaulted to integer PKs rather than bigint. Those PKs have a number
of integer FKs in related tables as well. We shouldn't have let them
get so big, but that's a conversation for another day.
Some are approaching overflow and we're slowly doing the work to
migrate to bigint. Mostly via the well understood "add a new id_bigint
column, populate on new tuples, backfill the old, switch the PK"
method. The backfill is slow on these large tables, but it works and
there's plenty of blog posts and documentation to follow.
It did make me curious though: would it be possible for postgres to
support gradual migration from integer to bigint in a more transparent
way, where new and updated tuples are written as bigint, but existing
tuples can be read as integer?
I assume maybe a complication is that the catalog says the column is
either 32bit int or 64bit bigint and making that conditional is hard.
There's presumably other considerations I'm unaware of too. My core
question: are there significant technical blockers to supporting this
kind of gradual in place migration, or has it just not been enough of
a problem that it's received attention?
James
