Postgresql - зміна розміру стовпчика варшара на меншу довжину

У мене питання щодо ALTER TABLEкоманди на дійсно великій таблиці (майже 30 мільйонів рядків). Один з його стовпців - це "a", varchar(255)і я хотів би змінити його розмір до "a" varchar(40). В основному, я хотів би змінити свій стовпець, виконавши таку команду:

ALTER TABLE mytable ALTER COLUMN mycolumn TYPE varchar(40);

У мене немає проблем, якщо процес дуже тривалий, але, здається, моя таблиця більше не читається під час команди ALTER TABLE. Чи є розумніший спосіб? Може бути додати новий стовпець, скопіювати значення зі старого стовпця, скинути старий стовпчик і нарешті перейменувати новий?

Будь-яка підказка буде дуже вдячна! Спасибі заздалегідь,

Примітка: я використовую PostgreSQL 9.0.

Опис того, як це зробити, можна змінити в розмірі стовпця в таблиці PostgreSQL без зміни даних . Ви повинні зламати дані каталогу баз даних. Єдиний спосіб зробити це офіційно - це ALTER TABLE, і, як ви зазначили, що зміна заблокує та перепише всю таблицю під час її запуску.

Переконайтесь, що ви прочитали розділ Типи символів у документах, перш ніж змінювати це. Тут слід пам’ятати про всілякі дивні випадки. Перевірка довжини проводиться, коли значення зберігаються у рядках. Якщо ви зламаєте нижню межу там, це зовсім не зменшить розмір існуючих значень. Було б розумно зробити сканування по всій таблиці, шукаючи рядки, де довжина поля> 40 символів після внесення змін. Вам потрібно буде з’ясувати, як обрізати їх вручну - щоб ви повернули деякі замки лише на великих розмірах - тому що, якщо хтось намагатиметься оновити що-небудь на цьому рядку, він зараз відкине його як занадто великий. він зберігається в новій версії рядка. Для користувача виникає веселість.

VARCHAR - жахливий тип, який існує в PostgreSQL лише для того, щоб відповідати пов'язаній з ним жахливій частині стандарту SQL. Якщо ви не переймаєтесь сумісністю декількох баз даних, подумайте про збереження даних як TEXT та додайте обмеження для обмеження його довжини. Обмеження, які ви можете змінити без проблеми з блокуванням / перезаписом таблиці, вони можуть перевірити цілісність, ніж просто перевірку слабкої довжини.

У PostgreSQL 9.1 є більш простий спосіб

http://www.postgresql.org/message-id/162867790801110710g3c686010qcdd852e721e7a559@mail.gmail.com

CREATE TABLE foog(a varchar(10));

ALTER TABLE foog ALTER COLUMN a TYPE varchar(30);

postgres=# \d foog

 Table "public.foog"
 Column |         Type          | Modifiers
--------+-----------------------+-----------
 a      | character varying(30) |

Гаразд, я, мабуть, спізнився на вечірку, АЛЕ ...

ВАШУ СПРАВУ НЕ БУДЕ ВІДГОТОВЛЯТИ КОЛІНУ!

Postgres, на відміну від деяких інших баз даних, досить розумний, щоб використовувати лише достатньо місця для розміщення рядка (навіть використовуючи стиснення для довших рядків), так що навіть якщо ваш стовпець оголошено як VARCHAR (255) - якщо ви зберігаєте рядки 40 символів у стовпця, використання місця буде 40 байт + 1 байт накладних витрат.

Вимога зберігання для короткого рядка (до 126 байт) становить 1 байт плюс фактичний рядок, який включає пробіл у випадку символів. Більш довгі рядки мають 4 байти накладних витрат замість 1. Довгі рядки стискаються системою автоматично, тому фізична потреба на диску може бути меншою. Дуже довгі значення також зберігаються у фонових таблицях, щоб вони не заважали швидкому доступу до коротших значень стовпців.

( http://www.postgresql.org/docs/9.0/interactive/datatype-character.html )

Специфікація розміру в VARCHAR використовується лише для перевірки розміру вставлених значень, це не впливає на макет диска. Насправді поля VARCHAR і TEXT зберігаються однаково в Postgres .

Я зіткнувся з тією самою проблемою, намагаючись урізати VARCHAR з 32 до 8 і отримати ERROR: value too long for type character varying(8). Я хочу залишатися якомога ближче до SQL, оскільки я використовую власну структуру, схожу на JPA, і нам, можливо, доведеться переходити до різних СУБД відповідно до вибору клієнта (за замовчуванням - PostgreSQL). Отже, я не хочу використовувати хитрість зміни системних таблиць.

Я закінчив використовувати USINGоператор у ALTER TABLE:

ALTER TABLE "MY_TABLE" ALTER COLUMN "MyColumn" TYPE varchar(8)
USING substr("MyColumn", 1, 8)

Як зауважив @raylu, ALTERексклюзивний замок на столі, тому всі інші операції будуть відкладені до його завершення.

Додаючи новий стовпець і замінюючи новий на старий, який працював для мене, на червоному зміні postgresql, перейдіть за цим посиланням для отримання детальної інформації https://gist.github.com/mmasashi/7107430

BEGIN;
LOCK users;
ALTER TABLE users ADD COLUMN name_new varchar(512) DEFAULT NULL;
UPDATE users SET name_new = name;
ALTER TABLE users DROP name;
ALTER TABLE users RENAME name_new TO name;
END;

Ось кеш сторінки, описаний Грегом Смітом. У разі, якщо він також відмирає, заява alter виглядає так:

UPDATE pg_attribute SET atttypmod = 35+4
WHERE attrelid = 'TABLE1'::regclass
AND attname = 'COL1';

Там, де ваша таблиця TABLE1, стовпець - COL1, і ви хочете встановити його на 35 символів (+4 необхідний для застарілих цілей за посиланням, можливо, накладні витрати, про які згадує AH у коментарях).

якщо ви вводите alter в транзакцію, таблиця не повинна блокуватися:

BEGIN;
  ALTER TABLE "public"."mytable" ALTER COLUMN "mycolumn" TYPE varchar(40);
COMMIT;

це спрацювало для мене, коли на столі з більш ніж 400 000 рядків лежало швидко, кілька секунд.

Я знайшов дуже простий спосіб змінити розмір, тобто анотацію @Size (min = 1, max = 50), яка є частиною "import javax.validation.constraints", тобто "import javax.validation.constraints.Size;"

@Size(min = 1, max = 50)
private String country;


when executing  this is hibernate you get in pgAdmin III 


CREATE TABLE address
(
.....
  country character varying(50),

.....

)

Спробуйте запустити наступну таблицю alter:

ALTER TABLE public.users 
ALTER COLUMN "password" TYPE varchar(300) 
USING "password"::varchar;