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

отлично, тогда вполне можно напихать в up.sql всяких команд типа \!, \i,
\o, \gset

цикл можно организовать например таким образом:

alexey_bashtanov@abashtanov-linux:~$ cat ~/c07.sql
select pg_sleep(0.1);
select case when random() > 0.9 then '/dev/null' else '~/c07.sql' end foo
\gset
\i :foo


On 09.09.2015 14:52, Dmitry E. Oboukhov wrote:
>> Что понимается под чистым 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