Webinar: Identity Columns and Generated Columns in PostgreSQL [Follow Up]

Identity Columns, initially rolled out in PostgreSQL 10, offer a standard-conforming and robust way to dynamically create auto-incrementing fields in tables. 

Generated Columns, computed from other columns, were first introduced in PostgreSQL 12. They enable more flexible schema design and performance benefits for your database. 

To cover the topic of “Identity Columns and Generated Columns in PostgreSQL” in more detail, 2ndQuadrant held a live webinar, hosted by Peter Eisentraut (CTO, 2ndQuadrant).

This webinar explored the different types of column methods with a focus on real-world use cases and detailed the difference between “generated always as identity” and “generated by default as identity” in PostgreSQL 12.

Those who weren’t able to attend the live webinar, can now view the recording here.

Due to limited time, some of the questions asked online were not answered during the live webinar; Peter’s replies are provided below:

Question: When you use override and insert value for identity, how does that affect the implicit sequence value?

Answer: The sequence is not changed if you use OVERRIDING SYSTEM VALUE. It is the user’s responsibility to make sure that manually inserted values do not conflict with current or future sequence values.

Question: Insert into tables overriding system value.. Can that be used to reset the next sequence value?

Answer: No, this does not change the sequence value. To change the sequence value, you can use the usual PostgreSQL function setval().

Question: Generated columns are computed again when updating a row *even when the base columns haven’t changed*. That’s inefficient and not negligible when the calculation is expensive.

Answer: This has been improved in PostgreSQL 13.

Question: How can I change an identity column to a bigger data type?

Answer: You can use the usual ALTER TABLE … ALTER COLUMN … TYPE command. This will also update the associated sequence accordingly. However, this command will lock and rewrite the table. To do this without extensive downtime requires custom techniques, such as copying the values into a new table gradually, perhaps using triggers or replication techniques. Therefore, it is recommended to plan the appropriate data type when the table is created.

To stay updated on upcoming webinars by 2ndQuadrant, you can visit our Webinars page.

For any questions, comments, or feedback, please visit our website or send an email to [email protected].