надо проделать пачку изменений типа:
ALTER COLUMN TYPE
на одной табличке.
(ну, вьюшку я сразу дропну, и потом подыму, вместе с руле, вопрос не в этом).

как честнее и правильнее с т.з. количества создаваемых версий и времени отработки скрипта: - делать пачку
или менять по одной колонке (будет увеличиваться длина VARCHAR-ов)?
(да, и "делетед" полей случаем не образуется?)


да, и если отдельными транзакциями - делать промежду них вакуум аналайз, или нет?

пока тестирую на тестовом клоне базки. Но табличка наверное под четверть-гига. одно поле сейчас алтериться за 150-170 сек. И вообще весь скрипт апдейта базы резать (с т.з. все той же теории - количества создаваемых версий) на отдельные транзакции, или не надо? (понятно, что на тестововй накатываю кусками).

понятно, что это скорее чисто постгрёвые заморочки - с DDL в транзакции.
Видимо ответов не будет?
(тут же разработчики мелькают - они-то наверняка знают механику отработки [альтер тейбла альтер колумн тайпа] именно постгресом?)




Вот еще смежная (для меня) мысль возникла: Если Temporary TABLE порождать INHERIT-анием стационарного образца, то , кажется, можно будет обращаться к записям темповой (на выборку и апдейт) через запрос к родителю? Вот только если индексы производить во временной - то использовать их удастся в функциях только через динамический SQL (пусть и к той же постоянной таблице). Правильно ли я тут себе намечаю финт ушами (на предмет пользования в транзакционных заливках тех же практически ф-й (переписав их на динамический скл - для задействования индексов темповок) и (постоянных) таблиц)? Или где-то принципиально вру?
Как ксати не динамический СКЛ отнесется к изменению состава наследников постоянной таблицы? Проигнорирует, учтет, или результат зависит от того, вызывалась ли эта ф-я уже в этой сессии?

Serik AkhmetovОбщепринятая практика, на время DDL всех из базы выгонять.
Не понятно, к чему вам эти навороты с транзакциями ?
DDL отлично выполняется в режиме auto-commit :)
После всего DDL рекомендуется делать vacuum analyze.

Про финты серым шрифтом, не понятно, чего вы хотите. ИМХО не оправданная сложность.
Напишите маленький примерчик и проверьте.
гм. как бы это попроще....
1. конечно же во время DDL (не темпового) будут предприняты соответсвующие меры. Не смотря на (блокировки то кажется ставятся постгресом по любому - Вот, черт, не помню, а ведь экспериментировал в своё. тут даже где то обсуждалась транзакционность постгресовского DDL, но все одно - _некоторые_ внешние прилады менять). Но хотелось бы таки побыстрее. А тут приходим к вопросу: как быстрее? Т.е. оно конечно "внутре у нее неонка", но вот какая? (про себя-то по темности-то можно думать - одной транзакции больше одной версии - оно ведь ни к чему. Нет?)

2. после всего - оно понятно. Но вот я делал копию для тренировок - из рабочей - темплейтом - так копия унаследовала какие-то проблемы рабочей с одной из табличек. Пришлось и там и там проделать реиндекс, иначе vacuum analyze намертво вис. Т.е. если при DDL делается что-то типа новой пачки версий, то не надо ли и между ними делать vacuum analyze?


3. про финты это тут немного левая тема. Интерес тут пока именно что теоретический. С примерчиком - оно понятно. Как разгребусь - так и накидаю, если не забуду. Просто некоторые вещи народ и навскидку может вспомнить.