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

Поиск
Список
Период
Сортировка

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

От
Andrey Lizenko
Дата:
Может быть, как-нибудь вот так?

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

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

От
Миша Тюрин
Дата:

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

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

От
"Dmitry E. Oboukhov"
Дата:
> Может быть, как-нибудь вот так?

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


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

--

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

Вложения

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

От
"Dmitry E. Oboukhov"
Дата:
Алгоритм то итак был понятен
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
--

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

Вложения

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

От
Alexey Bashtanov
Дата:
Что понимается под чистым 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@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



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

От
"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
--

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

Вложения

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

От
Alexander Law
Дата:
А 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@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



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

От
"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
--

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

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



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

От
Alexey Bashtanov
Дата:
отлично, тогда вполне можно напихать в 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