On Sun, Mar 3, 2024 at 2:06 PM yudhi s <learnerdatabas...@gmail.com> wrote:

> Hello,
> We have an application in which the tables will have approx ~200 columns
> in some of the big transaction tables when we will be serving all the
> business use cases. Currently it has ~100 columns to serve current business
> use cases to start with. As the team is following an agile approach , the
> attributes will be added gradually with each future release. But the
> concern is, the transaction tables will be holding billions of rows (
> because of historical data migration from start) and will be range
> partitioned and each of those partitions can be as big as ~100GB and full
> table size can be in multiple Terabytes.
>
> So our concern was , as the column addition using the traditional "Alter
> table" command in postgres looks to be a full table rewrite , it’s going to
> take a lot of time and resources with each of such releases for these big
> transaction tables. So what is the way to handle such scenarios and do
> these column additions in quick time with no/minimal downtime?
>

Normalizing the database design completely eliminates the problem of any
need to rewrite a table, since new attributes are added as new rows in a
different table.

Reply via email to