это на уровне бд делается, верно? если да, то печаль

секционирование да. параллелить по секциям можно наверное чем вам нравится

а вы на чём обработку пишете-то?

бизнес-логика на go

эх, спасибо. тогда пойду выбивать их инженеров секционирование

А ведь это, скорее всего, не поможет — только время зря потратите.
Впрочем, дело Ваше...

они вам будут задавать кучу вопросов например по какому ключу делать секционирование. по-моему вы недостаточно изучили проблему

к сожалению, не глубоко изучил проблему) признаю

если у вас выборка идет скажем 10 минут. а потом обрабатывается 2 часа, то вам ничего ускорять и не надо

у нас из-за таких больших запросов коннекты обрываются. в этом проблема. ресурсы не безграничны. иногда бывает так, что в нашу бд ходят другие сервисы, делают выборку, а в этом время и наши сервисы пытаются выбирать данные.
из-за этого cpu в потолок, i/o тоже, и отваливаются коннекты к бд из-за этого.
pgbouncer, конечно, тут тоже бессилен

подскажите плиз, обновлять временную таблицу в цикле через
UPDATE temp set ... WHERE  ... AND ... AND
правильно или есть какой-то более быстры способ ?

ну и на стейдже база часто ложится при тестировании. поэтому я и начал искать бронзовую пулю)

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

спасибо. но это уже будет совсем другая тяжелая история)
я надеялся на уровне запросов сделать.
ну и как подсказал Ярослав, понавтыкать индексов можно

размер индекса на 14 млн будет нехилым и он тоже будет читаться с диска. хотя он конечно меньше по размеру чем таблица должен быть

Тут я склонен согласиться, и я бы все-таки предложил обновлять частями, по скажем 10к товаров выбирая, как предложили выше по id > ... limit 10000

так всё таки лимит снизит нагрузку?
я как понял из ответа Ярослава, она не даст результата по кушанию ресурсов

Проблема в том как написан сервис на go, pgx (драйвер) сам использует курсоры. Похоже ваши разработчики выжирают данные в память сначала потом их плюют последовательно в кафку. Перепишите на каналы и складывайте каждую полученную строку в канал, а в другой рутине читайте и обрабатывайте. Есть такой шаблон в go pipeline. Это сильно разгрузит БД. Я делал интеграцию с oracle DB и переливал 40 млн записей в postgres сервисом на go. При вашем подходе потребление памяти на сервере го составляло около 10Гб, при пайплайне 300, почувствуйте разницу. Соответственно сервера БД тоже были загружены под самый потолок. Совет - переписывайте обработчик. БД в данном случае ведёт себя так как надо

вы только Сергею пишите, а не мне :)

Ой