Добрый день. Есть таблица на 500тыс записей. Регулярно приходят данные пакетам по

примерно 2тыс записей и ее необходимо обновлять.

Подскажите, какой алгоритм будет быстрее?

1. Удалить 2тыс записей за один delete и потом вставить при помощи одного insert.

Или

2. Сделать 2 тыс update запросов.

Интуитивно кажется что первый вариант будет быстрее, за счёт того что будет только 2 запроса

Возможно есть какой-то более производительный способ для массового обновления данных в таблице?

Быстрее будет сделано, скорее всего, то, что вам понятнее.

Не очень понял) «Понятнее»?

Да. Меньшэ кода, код проще, меньшэ плохо запоминаемых связей в коде. Смотреть на скорость компьютэров при таких маленьких объёмах чаще всего не имеет смысла. В задачах, в которых имеет смысл — их не имеет смысла решать без нормальных инжэнерных измерений. Определение нагрузки, определение, что такое "быстрее/медленнее", определение жэлеза, создание стэнда, набор повторяемых реалистичных измерений, вот это всё. Решать их голосованием в чятиках смысла никакого нет. Да и, в любом случае, скорее всего ваша скорость будет зависеть от каких-то странных особенностей вашэго загрузчика. Так что дажэ гадать — что будет у вас быстрее — смысла никакого нет, дажэ если будет более полная информацыя о таблицах.

Все равно не понимаю мысль. Написать меньше кода или упростить его - такой цели не стоит. Скорость компьютера - тоже речь не про это. Вопрос стоит не как уложить данный процесс в секунду, а как эффективней использовать то что есть. Вопрос в том сколько манипуляций необходимо сделать постгресу чтобы добиться нужного результата. Например, вставить 2000записей при помощи 2000 insert-ов будет гарантированно медленнее чем один insert с 2000 записями. Мы потратимся на отправку большего sql кода, парсинг каждого запроса и тп. В случае с удалением и последующей вставкой, или апдейтами мне сложно оценить какой алгоритм будет проще для постгреса без понимания какие реальные операции нужно будет ему сделать. Я могу сделать простой замер, и собственно так и сделаю, но хочется 1) не только знать что так будет быстрее, но и понимать почему. 2) я могу выбрать более быстрый алгоритм но получить негативное фоновое воздействие, которое может аукнутся. Поэтому интересуюсь здесь

А вы сделайте препарированный запрос и не надо будет парсить.

О, пойду почитаю об этом

Стесняюсь спросить, у вас в пакете из 2к записей все существуют в исходном наборе?

а зачем удалять и вставлять? почему не сделать один апдейт на 2к записей? При отсутствии каких-то хитрых условий, - конечно лучше делать пачкой по 2к, чем в цикле посылать 2000 запросов. Причин много: один апдейт на 2к строк будет быстрей, чем 2к апдейтов 1 network раундтрип vs 2к раундтрипов работа с WAL более эффективная при 1 апдейте

А-а. Пан спортсмен. Ну, тренируйтесь тогда, да. Только непонятно — нафига спрашывать совсем детские вопросы, которые в большом спорте по перекладыванию байтов в памяти решаются буквально одним измерением. Да что там одним измерением — любой спортивный забег начинается с написания секундомера, который призван давать ответ на этот вопрос.

>1) не только знать что так будет быстрее, но и понимать почему. Получая странные советы от рандомных людей в чятике — вы в любом случае не приблизитесь к реальному пониманию. (Рассматривая результаты измерений — приблизиться можно. Ещё читая код постгреса. Ещё совмещая эти две активности. Задавая абстрактные вопросы инжэнерам — нет, так только философия изучается, а не инжэнерия).

>2) я могу выбрать более быстрый алгоритм но получить негативное фоновое воздействие, которое может аукнутся. Притом примерно всегда. Потому небывает абстрактного "быстро" (бывает абстрактное "медленно"), но всё хорошо по обстоятельствам и требует комплексных измерений.

А как сделать апдейт 2к записей за один запрос? Здесь идет апдейт не одного поля, а сразу всех колонок

Да

https://www.postgresql.org/docs/16/sql-update.html Не лимитирует количество обновляемых записей за один запрос.

Есть таблица id,name,age 1,Вася,23 2,Петр,27 Как можно в один апдейт поменять значения на: 1,Василий,23 2,Петр,28 Я посмотрел страницу что вы скинули, но не понимаю как это возможно

>> Не бывает абстрактного быстро. Я же пишу, мне важно не быстро/медленно. Мне важно быстрее/медленнее. Сложность алгоритма именно про это.

Например, так: https://sqlize.online/sql/psql15/459a411748ccf9b142f15b2455ab8ff2/

Не бывает абстрактного "быстрее".

Спасибо!

Если клиентская библиотека/API/драйвер/как-оно-там-называется для доступа к PostgreSQL в используемом "клиентском" PL не совсем уж безнадёжна, то приемлемых вариантов полно. Вот пара примеров: https://sqlize.online/sql/psql15/3b2cb5e52fa56dfd1501fab26ce8b190/

Вот это вообще выглядит круто