Pull to refresh

Comments 18

Большое спасибо, на днях чудил с криптоагрегатором и с API подгружал кучу данных, пригодится. Кажется что база, но тут есть некоторые тонкости для меня. А может кто-то порекомендовать хороший курс или книжку по Postgre?

https://www.postgrespro.ru/education/courses
Ну как минимум вот эти курсы довольно хороши

Из книг - ну если нужно что-то на русском языке - опять же от этих ребят есть 2 книги по постгресу. Одна у Рогова, вторая у Моргунова

Пересоздать индекс, отключить триггеры? Вы серьезно? На рабочей базе?

Если БД используется как olap, то всё это рабочие схемы. Переливки во временные таблицы, отключение репликации, расчёт на партициях, блин да даже ram диск использовать это вполне норм. Да, тогда надо брать спарк, но тут речь про постгрю :-)

Если для статики, то наверное и возможно, в том числе и на PG, если динамическая часть тоже на нём. Но откуда в статике триггеры?

По ходу автор только в песочнице копировал данные, так как на живой базе отключение индексов == можно всем идти на обед, а деактивация тригерров вообще чревата потерей части бизнес логики

Ну а пакетная обработка одним update даже на уровень песочницы не тянет

Вот это

FOR r IN (SELECT id FROM source_table WHERE condition) LOOP DELETE FROM target_table WHERE id = r.id; END LOOP;

будет работать на порядок дольше, чем

DELETE FROM target_table WHERE id in (SELECT id FROM source_table WHERE condition)

Вообще если предполагается какое-то массовое удаление и речь зашла про доп. подготовки вроде отключения триггеров, то есть еще вариант - таблицу готовим в рид онли, на её основе создаем новую через `create as select` и переименовываем новую в старую, а старую потом дропаем, иначе это удаление вообще может зависнуть)))

Вот это

FOR r IN (SELECT id FROM source_table WHERE condition) LOOP DELETE FROM target_table WHERE id = r.id; END LOOP;

будет работать на порядок дольше, чем

DELETE FROM target_table WHERE id in (SELECT id FROM source_table WHERE condition)

Вот это

FOR r IN (SELECT id FROM source_table WHERE condition) LOOP DELETE FROM target_table WHERE id = r.id; END LOOP;

будет работать на порядок дольше, чем

DELETE FROM target_table WHERE id in (SELECT id FROM source_table WHERE condition)

Вот это

FOR r IN (SELECT id FROM source_table WHERE condition) LOOP DELETE FROM target_table WHERE id = r.id; END LOOP;

будет работать на порядок дольше, чем

DELETE FROM target_table WHERE id in (SELECT id FROM source_table WHERE condition)

Так можно вставить 1000 записей в таблицу my_table в рамках одной процедуры.

Так можно только по рукам получить. Ну или по голове. generate_series() для кого придуманы?

Пакетное удаление данных с PL/pgSQL

И за это тоже бить будут. DELETE имеет опциональный USING clause. Именно для таких целей.

Плюсом можно подключить нелогируемые таблицы и поработать с настройкой work_mem.

Что, зачем это делать, как это поможет и при каких условиях ?

DO $$
BEGIN
  FOR i IN 1..1000 LOOP
    INSERT INTO my_table (column1, column2)
    VALUES (i, i * 2);
  END LOOP;
END $$;

А это что такое, почему не generate_seriaes ? ( тот же вопрос и про удаление ( коммент был выше, да и вообще, почему не транкейт ? )

Раз уж массовая производительная обработка, то почему нет `merge` ?

Просто вброс какой-то инфы, взятой из разных источников, вообще не информативно ничего.

индексы то ладно, их переидексировать можно. Но триггеры то не просто так висят на таблице.

Круто, конечно, что у нас бизнес-логика сломается, но не очень

Автор про партиции что-нибудь слышал?

Автор про мусор и вакумм что-нибудь слышал?

Можно, конечно, над таблицей и так плясать и эдак, но почему бы не ограничить доступ к таблице, если уж она никому не нужна, без индексов и тригеров-то? Я бы уж тогда и fk прибил бы. Можно ж восстановить.

Есть и другие способы избавиться/обновить записи. Но надо сначала те что выше отработать.

А есть ли вариант напрямую из xml файла раскладывать содержимое тегов или атрибутов по порядку в колонки таблицы?

Конечно, можно. XML - это же текст. Текстовых функций в постгрессе - вагон и маленькая тележка, распарсить можно что угодно и как угодно.

Хотя это дурь, конечно. Ибо в Постгрессе есть и горсть XML-функций. В том числе XMLTABLE().

Sign up to leave a comment.