Size: a a a

pgsql – PostgreSQL

2021 March 18

IZ

Ilia Zviagin in pgsql – PostgreSQL
Radist
Вам в итоге нужно получить таблицу с value inet или просто зачистить то, что не проходит валидацию? В табличку в это время кто-то пишет?
Если нужно тип сменить, то create table xxx as select key, value::inet from таблица where value ~ регексп.
Если менять тип не надо и в неё кто-то пишет - создавайте not valid констрейнт по условию корректности адреса, затем удаляйте кривые строки и делайте validate constraint (это, вроде, можно без блокировки всей таблицы сделать). В остальных случаях тупо delete по условию. Да, медленно, но тут ничего не поделаешь.
@rrrrad , 5 не миллионов, и миллиардов, какой ещё delete?
источник

YS

Yaroslav Schekin in pgsql – PostgreSQL
Ilia Zviagin
Не, delete не вариант.

Большая таблица
Хмм... и почему же?
источник

n

nibble in pgsql – PostgreSQL
Сергей Кравчук
нууу, с базой все в порядке
проблема думаю где-то между базой и клиентом
открытые порты на машине, пробросы в докере и вот это вот все
а база похоже полностью здорова
спасибо шеф, буду пробовать менять порты
источник

R

Radist in pgsql – PostgreSQL
Гм. Вообще-то зависит от того, как регексп написать. У вас, по сути, вариантов не очень много. Если проблема в производительности регекспа - напишите функцию на c
источник

IZ

Ilia Zviagin in pgsql – PostgreSQL
Yaroslav Schekin
Хмм... и почему же?
Да потому что он никогда не закончится
источник

JD

John Doe in pgsql – PostgreSQL
запустил запрос SELECT * FROM tab where value ~ regexp limit 1- за 3 часа - не выполнился...
источник

YS

Yaroslav Schekin in pgsql – PostgreSQL
John Doe
можно оба варианта... таблица временная, никто не пишет кроме меня
value ~ regexp - работает оооооочень долго, непредсказуемо долго
А какой regexp? В общем, показали бы Вы то, что у Вас есть — \d и \dt таблицы, и запрос, которым удаляете.
источник

b

batyrmastyr in pgsql – PostgreSQL
Artem D.
Сам код довольно старыйвряжли джсон будет пока использоваться, возможен ли прирост производительности?
Из легко заметного:
1. btree индексы стали занимать в 3 раза меньше места и ощутимо быстрее.
2. В 13  ORDER BY a, b может использовать индекс по a и досортировать по b, до этого нужен был индекс именно a, b.
3. В 10-м постгресе LIKE не умеет ускоряться за счёт триграммных индексов, а регулярки не используют SPGIST. В 13-м работают почти все комбинации (LIKE 'bla' ускорят в 14-м), хотя LIKE по триграммам всё равно в 2-3 раза медленнее регулярок ищет. Но это где-то в 11 и 12 ускорили.
источник

YS

Yaroslav Schekin in pgsql – PostgreSQL
Ilia Zviagin
Да потому что он никогда не закончится
Закончится, куда он денется. А альтернатива, кстати, какая?
источник

JD

John Doe in pgsql – PostgreSQL
Yaroslav Schekin
А какой regexp? В общем, показали бы Вы то, что у Вас есть — \d и \dt таблицы, и запрос, которым удаляете.
regexp поставил '[a-z]' (строки с буквой в любом месте)
источник

IZ

Ilia Zviagin in pgsql – PostgreSQL
Yaroslav Schekin
Закончится, куда он денется. А альтернатива, кстати, какая?
Курсором бежать по записям, проверять валидность, удалять по одной плохие строки (либо что-то ещё делать с ними).

Так хоть прогресс гарантирован.


Ну и это конечно не неделю работать будет, месяца два...
источник

YS

Yaroslav Schekin in pgsql – PostgreSQL
John Doe
regexp поставил '[a-z]' (строки с буквой в любом месте)
Я попросил три вещи показать, нет?
источник

JD

John Doe in pgsql – PostgreSQL
Yaroslav Schekin
Я попросил три вещи показать, нет?
на телефоне доступа нет к данным, извините... )
источник

JD

John Doe in pgsql – PostgreSQL
таблица загружалась с помощью copy from 2 дня, попробую еще вариант почистить исходный csv и загрузить заново... может так быстрее будет...
источник

YS

Yaroslav Schekin in pgsql – PostgreSQL
Ilia Zviagin
Курсором бежать по записям, проверять валидность, удалять по одной плохие строки (либо что-то ещё делать с ними).

Так хоть прогресс гарантирован.


Ну и это конечно не неделю работать будет, месяца два...
И это будет тупо гораздо дольше, больше ничего.
Вот из какой СУБД у Вас такие привычки, где разработчики умудрились так накосить, что у них курсор работает быстрее простого DELETE FROM, а? ;)
источник

IZ

Ilia Zviagin in pgsql – PostgreSQL
Ilia Zviagin
Курсором бежать по записям, проверять валидность, удалять по одной плохие строки (либо что-то ещё делать с ними).

Так хоть прогресс гарантирован.


Ну и это конечно не неделю работать будет, месяца два...
Ещё хорошо бы сохранять периодически обработанный диапазон id, чтобы при сбое можно было бы вернуться к началу этого диапазона, а не с нуля все
источник

IZ

Ilia Zviagin in pgsql – PostgreSQL
Yaroslav Schekin
И это будет тупо гораздо дольше, больше ничего.
Вот из какой СУБД у Вас такие привычки, где разработчики умудрились так накосить, что у них курсор работает быстрее простого DELETE FROM, а? ;)
Я не говорил что будет быстрее.
источник

YS

Yaroslav Schekin in pgsql – PostgreSQL
John Doe
на телефоне доступа нет к данным, извините... )
Так покажите, когда будет. Там вполне может быть полезная информация, которой Вы пока не показали.
источник

JD

John Doe in pgsql – PostgreSQL
Yaroslav Schekin
Так покажите, когда будет. Там вполне может быть полезная информация, которой Вы пока не показали.
хорошо) спасибо за помощь
источник

AL

Alexey Lesovsky in pgsql – PostgreSQL
nibble
спасибо шеф, буду пробовать менять порты
погодите, вы тут написали что все проверки успешны, но при этом снаружи к базе никто не может подключиться? это слегка противоречит пункту с ss.

покажите docker-compose ps грепнув вывод по имени контейнера с БД
источник