Clarifed table rewrites in migration docs.

Small nitpicks. All column-related ALTER TABLE commands take an
exclusive table lock in PostgreSQL. The difference is that adding a
column without default doesn't cause a table rewrite, so the lock is
held only for a short time.

The time taken is more accurately proportional to table size, not row
count.
This commit is contained in:
Marti Raudsepp 2013-12-12 21:26:57 +02:00 committed by Tim Graham
parent 6685713869
commit 75ec1fdf16
1 changed files with 6 additions and 6 deletions

View File

@ -70,7 +70,7 @@ PostgreSQL
PostgreSQL is the most capable of all the databases here in terms of schema
support; the only caveat is that adding columns with default values will
lock a table for a time proportional to the number of rows in it.
cause a full rewrite of the table, for a time proportional to its size.
For this reason, it's recommended you always create new columns with
``null=True``, as this way they will be added immediately.
@ -83,11 +83,11 @@ meaning that if a migration fails to apply you will have to manually unpick
the changes in order to try again (it's impossible to roll back to an
earlier point).
In addition, MySQL will lock tables for almost every schema operation and
generally takes a time proportional to the number of rows in the table to
add or remove columns. On slower hardware this can be worse than a minute
per million rows - adding a few columns to a table with just a few million
rows could lock your site up for over ten minutes.
In addition, MySQL will fully rewrite tables for almost every schema operation
and generally takes a time proportional to the number of rows in the table to
add or remove columns. On slower hardware this can be worse than a minute per
million rows - adding a few columns to a table with just a few million rows
could lock your site up for over ten minutes.
Finally, MySQL has reasonably small limits on name lengths for columns, tables
and indexes, as well as a limit on the combined size of all columns an index