А что такое "bulk insert"?

Трудности перехода с  MS SQL 😁

Добрый день. Есть 100 сущностей. У всех сущностей десяток одинаковых полей, и от 1 до десятка разных полей (если провести аналогию с ООП это один родительский класс и 100 наследников).
Опытные товарищи, подскажите, как лучше спроектировать БД на postgreSQL? Сделать 100 таблиц с десятком одинаковых полей в каждой, сделать 100 таблиц с уникальными полями и 1 базовую таблицу с общими полями, или сделать одну таблицу с 100+ полями?

подумайте над вариантами как уменьшить количество партиций (понятно что задача не на 5 минут) - желательно сделать где-то сбоку тестовый стенд где можно легко воспроизводить проблему и проверять гипотезы

рассмотрите вариант перехода на pg 12 или 13, там были значительные улучшения в плане партиционирования как раз для случаев с тысячами партиций (опять же с предварительной проверкой на тестовом стенде)

спасибо, смотрю уже в сторону апгрейда

Коллеги, добрый день.

Есть таблица вида
id | key (unique constraint) | occurance

Нужно увеличивать occurance на единицу для строки, если вставляется строка с существующим key.

Наивное решение сделать это средствами pg используя upsert on conflict.

Количество вставок предполагается до ~2k/sec. Предполагаемое количество конфликтов при вставке ~50%.

Вопрос: нормально ли переживет pg около 1000 обновлений в секунду. Если да, то нужно ли сразу смотреть в сторону уменьшения fillfactor?

И всё равно не стоит тысячи partitions использовать (т.е. в 12/13 стало не так плохо, как раньше, вот и всё).

Сгенерируйте тестовые данные да и померяйте, на своём железе / нагрузке / ситуации, да и всё.

Да, но я  хотел услышать еще об опыте других людей.

тут скорее "трудности перевода c orm)) bulk insert это когда мы одним insertom пушем несколько записей.

insert into tt (text) values ('So now, eins zwei drei' ),('Soon we will synchronize'),('So now, eins zwei drei'),('Escaping our demise');

> Вопрос: нормально ли переживет pg около 1000 обновлений в секунду.

тут отчасти производительность будет зависесть от дисковой подсистемы - по идее если такой поток записи более/менее постоянен, то диски должны вывозить и саму запись и периодически выполняющиеся фоновые чекпоинты во время которых может проседать производительность основных инсертов. поэтому если будете делать тесты, делайте их продолжительные по времени (10-20-30 минут)

Хорошо, спасибо!

вцелом есть инсталляции где 2k инсертов не проблема, да и железо тоже не сказать что космос

тут скорее вопрос в обновлениях, на другом проекте вставлял тоже 2-3к и все было ок.

Вы понимаете, что у некоторых людей "железо" на том, что они называют "сервером" похуже, чем в любом современном смартфоне; а у других, например (первое, что вспомнилось) 1.5 TB, 40 cores, 512G ram, 10 SSD x RAID10 — это "базовый" сервер под любой новый кластер (т.е. таких много "в запасе")?
И вот толку Вам от этого? ;)

Понимаю, но можно попробовать аппроксимировать чужие цифры на свои.

insert into tt (text) values ('So now, eins zwei drei' ),('Soon we will synchronize'),('So now, eins zwei drei'),('Escaping our demise');

Тогда ответ — только/каждая строка.
Но не так, как в Вашем примере — ON CONFLICT не для устранения дубликатов во вставляемых данных, а только для случая, когда вставляемые данные дублируют те, что уже есть в БД.

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

Привет. Получаю такую ошибку в логах  Executed roolback on connection org.postgresql.jdbc.PgConnection@ due to dirty commit state close.

может ли она возникать из-за нехватки места на диске? или какие еще причины?

Это точно не postgres-овская ошибка, по крайней мере.
Можно там как-то узнать, что выдал PostgreSQL (ну или в его логах посмотрите, если там вообще что-то есть)?