> On Mar 3, 2024, at 12:00, Christophe Pettus wrote:
> Remember that dropping the NULL constraint afterwards will require a full
> table read (although not a rewrite).
Sorry, badly put: Adding a NOT NULl constraint afterwards will require a full
table read (although not a rewrite).
> On Mar 3, 2024, at 11:40, yudhi s wrote:
> Thanks for the clarification. In case of adding the column as volatile
> default (like current_timestamp function as default) or say adding NOT NULL
> column with some conditional population of existing values will be a full
> table rewrite. In su
On Mon, Mar 4, 2024 at 12:43 AM Christophe Pettus wrote:
>
> > On Mar 3, 2024, at 11:06, yudhi s wrote:
> > as the column addition using the traditional "Alter table" command in
> postgres looks to be a full table rewrite
>
> That's not always (or, really, usually) true. Adding a new column in
On Sun, Mar 3, 2024 at 2:06 PM yudhi s 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 st
> On Mar 3, 2024, at 11:06, yudhi s wrote:
> as the column addition using the traditional "Alter table" command in
> postgres looks to be a full table rewrite
That's not always (or, really, usually) true. Adding a new column in any
recent version of PostgreSQL just alters the system catalog
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
