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

есть огромная таблица на неск. десятков млн строк

в ней есть поле 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

Может быть, как-нибудь вот так?

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

Пересоздать таблицу: 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 < 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

> Может быть, как-нибудь вот так?

> http://www.databasesoup.com/2015/08/lock-polling-script-for-alter-table.html

а разве секция DO не выполняется целиком всегда в одной транзакции?

--

. ''`. 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

Алгоритм то итак был понятен
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
--

. ''`. 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

Что понимается под чистым SQL?
Можно ли, например, пользоваться командами psql, начинающимися с backslash?
Если да, то цикл, необходимый для п.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

> Что понимается под чистым 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
--

. ''`. 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

А CREATE FUNCTION convert_table() ... / SELECT convert_table() это
достаточно чистый SQL?

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

> А 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

Может быть тогда сделать триггер, который будет при изменении 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(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

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

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

alexey_bashtanov(at)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(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