| From: | "Dmitry E(dot) Oboukhov" <unera(at)debian(dot)org> |
|---|---|
| To: | Alexander Law <exclusion(at)gmail(dot)com> |
| Cc: | pgsql-ru-general(at)postgresql(dot)org |
| Subject: | Re: Re: [pgsql-ru-general] Re: Re: Re[2]: [pgsql-ru-general] Неблокирующий запрос |
| Date: | 2015-09-09 12:34:34 |
| Message-ID: | 20150909123434.GF23119@vdsl.uvw.ru |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | 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(at)gmail(dot)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(at)debian(dot)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(at)debian(dot)org jabber://UNera(at)uvw(dot)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(at)postgresql(dot)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(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-ru-general
--
. ''`. Dmitry E. Oboukhov
: :’ : email: unera(at)debian(dot)org jabber://UNera(at)uvw(dot)ru
`. `~’ GPGKey: 1024D / F8E26537 2006-11-21
`- 1B23 D4F8 8EC0 D902 0555 E438 AB8C 00CF F8E2 6537
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alexander Law | 2015-09-09 12:57:53 | Re: [pgsql-ru-general] Re: [pgsql-ru-general] Re: Re: Re[2]: [pgsql-ru-general] Неблокирующий запрос |
| Previous Message | Alexander Law | 2015-09-09 12:12:12 | Re: [pgsql-ru-general] Re: Re: Re[2]: [pgsql-ru-general] Неблокирующий запрос |