Re: [pgsql-ru-general] Re: [pgsql-ru-general] Re: Re: Re[2]: [pgsql-ru-general] Неблокирующий запрос

Может быть тогда сделать триггер, который будет при изменении col2
отражать изменение в col1 и потом пройтись хоть таким же сгенерированным
SQL  UPDATE SET col2=col2 WHERE ... по таблице...



09.09.2015 15:34, Dmitry E. Oboukhov пишет:
>> А CREATE FUNCTION convert_table() ... / SELECT convert_table() это
>> достаточно чистый SQL?
> да достаточно чистый.
> равно как и DO .. END.
> проблема в том что весь цикл в DO .. END или в функции будет идти
> возможно несколько часов, а все это время хочется чтобы БД продолжала
> работать (задача сапгрейдить боевую БД).
>
>
>> 09.09.2015 14:52, Dmitry E. Oboukhov пишет:
>>>> Что понимается под чистым SQL?
>>>> Можно ли, например, пользоваться командами psql, начинающимися с backslash?
>>> я говорил выше: имеется инфраструктура которая запускает
>>> psql bla < up.sql
>>> psql bla < down.sql
>>>
>>> :)
>>>
>>> вот эту инфраструктуру патчить не хочу
>>>
>>>> Если да, то цикл, необходимый для п.3, можно написать с помощью SQL
>>>> interpolation и инклюда файлов.
>>>> Если нет, то скорее всего ничего не получится: коммит транзакции
>>>> невозможно сделать из функции, поэтому каждый коммит придётся писать
>>>> в файл непосредственно.
>>>> Чтобы решить, как разбивать таблицу на пачки для апдейта, надо знать
>>>> её схему, индексы, и какая активность на ней происходит.
>>>> Алексей Баштанов
>>>> On 09.09.2015 11:42, Dmitry E. Oboukhov wrote:
>>>>> Алгоритм то итак был понятен
>>>>> 1. добавляем null поле (бесплатно)
>>>>> 2. строим concurently индекс по этому полю
>>>>> 3. заполняем неторопясь это поле
>>>>> 4. далее в транзакции дозаполняем остаток,
>>>>>     добавляем not null на это поле (помогает индекс),
>>>>>     переименовываем столбики
>>>>>
>>>>> вопрос можно ли это проделать на чистом SQL
>>>>>
>>>>>> Пересоздать таблицу: select все_поля_с_подменой_енума_на_текст into tbl_new
>>>>>> from tbl; rename tbl to tbl_old; rename tbl_new to tbl; потом можно и дропнуть
>>>>>> tbl_old. Ну это с даунтаймом.
>>>>>> Иначе все сложнее. Можно временно совмещать на вьюшке два поля в одно, пока в
>>>>>> фоне идёт апдейт. Потом вьюшку убрать. При этом новое все сразу вставлять/
>>>>>> апдейтить по новой схеме. После внедрения новой схемы до убирания вьюшки все
>>>>>> разом вычитать и потом через очередь апдейтить пачками. Ну и тут тоже с локами
>>>>>> надо костылить по типу как ссылка из блога.
>>>>>> --
>>>>>> Отправлено из Mail.Ru для Android
>>>>>> вторник, 08 сентября 2015г., 15:46 +03:00 от Andrey Lizenko <
>>>>>> lizenko79@gmail.com>:
>>>>>> Может быть, как-нибудь вот так?
>>>>>> http://www.databasesoup.com/2015/08/
>>>>>> lock-polling-script-for-alter-table.html
>>>>>> 2015-09-08 14:07 GMT+03:00 Dmitry E. Oboukhov <: <http://
>>>>>> www.databasesoup.com/2015/08/lock-polling-script-for-alter-table.html"
>>>>>> target="_blank" >http://www.databasesoup.com/2015/08/
>>>>>> lock-polling-script-for-alter-table.html
>>>>>> 2015-09-08 14:07 GMT+03:00 Dmitry E. Oboukhov unera@debian.org>:
>>>>>> есть огромная таблица на неск. десятков млн строк
>>>>>> в ней есть поле  ENUM.
>>>>>> хотим преобразовать его в TEXT.
>>>>>> Можно ли это сделать на чистом SQL?
>>>>>> то есть ALTER TABLE .. ADD COLUMN col TEXT;
>>>>>> не будет блокироваться,
>>>>>> далее надо его заполнить значением из ENUM и после этого можно будет
>>>>>> сделать rename.
>>>>>> проблема в том что имеется действующая инфраструктура
>>>>>> апгрейда-даунгрейда БД и она предполагает только up.sql, down.sql.
>>>>>> соответственно можно написать сколько угодно инструкций но на SQL а не
>>>>>> на другом Я.П.
>>>>>> можно ли извратнуться как-то и сделать аналог
>>>>>> UPDATE
>>>>>> table
>>>>>> SET
>>>>>> col1 = col2
>>>>>> WHERE
>>>>>> col1 IS NULL
>>>>>> неубивающим БД?
>>>>>> пока в голову пришло только сгенерить этот самый SQL чтобы по 1000
>>>>>> записей сделал явно больше UPDATE'ов чем есть в БД записей и далее
>>>>>> уже в транзакции доделал те что еще остаются недоделанными и
>>>>>> переименовал бы столбики.
>>>>>> --
>>>>>> . ''`.                               Dmitry E. Oboukhov
>>>>>> : :’  :   email: unera@debian.org jabber://UNera@uvw.ru
>>>>>> `. `~’              GPGKey: 1024D / F8E26537 2006-11-21
>>>>>> `- 1B23 D4F8 8EC0 D902 0555  E438 AB8C 00CF F8E2 6537
>>>>>> -----BEGIN PGP SIGNATURE-----
>>>>>> Version: GnuPG v1.4.10 (GNU/Linux)
>>>>>> iEYEAREDAAYFAlXuwW0ACgkQq4wAz/jiZTdO3QCgyj5UOlnMbTkaRGv3q9bLbdml
>>>>>> kfgAn29M2yTnhQ+157VkCXdTjuwo4q/X
>>>>>> =Mk2J
>>>>>> -----END PGP SIGNATURE-----
>>>>>> --
>>>>>> Regards, Andrey Lizenko
>>>> --
>>>> Sent via pgsql-ru-general mailing list (pgsql-ru-general@postgresql.org)
>>>> To make changes to your subscription:
>>>> http://www.postgresql.org/mailpref/pgsql-ru-general
>> --
>> Sent via pgsql-ru-general mailing list (pgsql-ru-general@postgresql.org)
>> To make changes to your subscription:
>> http://www.postgresql.org/mailpref/pgsql-ru-general