Re: Re: [pgsql-ru-general] Re: Re: Re[2]: [pgsql-ru-general] Неблокирующий запрос
От | Dmitry E. Oboukhov |
---|---|
Тема | Re: Re: [pgsql-ru-general] Re: Re: Re[2]: [pgsql-ru-general] Неблокирующий запрос |
Дата | |
Msg-id | 20150909123434.GF23119@vdsl.uvw.ru обсуждение исходный текст |
Ответ на | Re: [pgsql-ru-general] Re: Re: Re[2]: [pgsql-ru-general] Неблокирующий запрос (Alexander Law <exclusion@gmail.com>) |
Список | pgsql-ru-general |
> А 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 -- . ''`. 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
Вложения
В списке pgsql-ru-general по дате отправления:
Предыдущее
От: Alexander LawДата:
Сообщение: Re: [pgsql-ru-general] Re: Re: Re[2]: [pgsql-ru-general] Неблокирующий запрос
Следующее
От: Alexander LawДата:
Сообщение: Re: [pgsql-ru-general] Re: [pgsql-ru-general] Re: Re: Re[2]: [pgsql-ru-general] Неблокирующий запрос