Search Postgresql Archives

Cases where alter table set type varchar(longer length) still needs table rewrite

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Good morning!

We are a little bit puzzled because running the following command on a 9.6 cluster is apparently requiring a table rewrite, or at least a very long operation of some kind, even though the docs say that as of 9.2:

  • Increasing the length limit for a varchar or varbit column, or removing the limit altogether, no longer requires a table rewrite. Similarly, increasing the allowable precision of a numeric column, or changing a column from constrained numeric to unconstrained numeric, no longer requires a table rewrite. Table rewrites are also avoided in similar cases involving the intervaltimestamp, and timestamptz types.

I have a table foo with 100 million rows, and a column:
  • id character varying(20)
The following command is the one that we expect to execute very quickly (we are not seeing any locking), but it is instead taking a very long time:
  • ALTER TABLE foo ALTER COLUMN id TYPE varchar(100);
I attempted the same operation instead cast to text - same problem.

Why do the docs seem wrong in our case?  I have a guess: if the table was created prior to version 9.2, perhaps they are not binary coercible to text after 9.2?  In any case, I would be very grateful for an explanation!


Thank you!
Jeremy

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]

  Powered by Linux