А если не секрет, что в приложении пришлось поменять?
В моей команде тоже скоро будет обновление...

Я вот сходу не могу понять, что кроме connection string нужно изменить в приложении.

Если будете обновлять дистрибутив, то смотрите за сменой версии glibc. Скорей всего придется перестраивать индексы.
https://wiki.postgresql.org/wiki/Locale_data_changes

Знаю, что раньше CTE использовали с учётом того, что она материализуется. Но моя новая команда не использовала CTE похоже, в коде не вижу... Что ещё может быть ещё такого?

Zabbix-server и прокси сервера обновляли с 4 версии на 5-ю + ставил расширение TimescaleBD

По сути я ничего не менял, я просто развернул новые сервера и после миграции БД выключил старые сервера и включил новые.

Спасибо

> Вы читали моё сообщение вот тут https://t.me/pgsql/291622?

Да, читал. А Вы уже прочитали https://t.me/pgsql/291702 ?

> Т.е. в статье паттерн использования явно заточен под b-tree, где преобладает чтение + рандомное обновление. Я в курсе, что это самый распространённый паттерн.

https://xkcd.com/285/ ;)
Т.е. я, например, не в курсе, что это "самый распространённый паттерн". Откуда это утверждение?

> Запись на носители быстрее, когда данные пишутся большими кусками на диск bulk операцией, как в случае LSM.

Хмм... допустим, но в "типичных" реляционных СУБД данные пишутся на диск именно таким образом очень часто, независимо от используемых структур данных (типов индексов).

> Уверен, что LMDB "проиграет", так как будет точечно записывать на диск каждый раз на вставку и обновление.

И уверены совершенно зря, см. сообщение по ссылке.

> Кстати, у Константина есть дополнительные требования к тому, чтобы LSM "выиграл" у LMDB

И что я (и PostgreSQL hackers, и разработчики других СУБД) про эти требования думаю, я написал в том сообщении.

> Единственное, что доказывает данная статья (это на мой взгляд), что LMDB идеально подходит для небольших устройств, типо смартфонов, по сравнению с другими БД в этой статье.

Т.е. по ссылке внутри статьи ( http://www.lmdb.tech/bench/inmem/large.html ) Вы тоже не сходили?
"We proceeded to test a workload with a 1000M (one billion) record ~120GB database on our server with only 128GB of RAM."
Типичный смартфон, ага.

> Наверное Вы всё-таки забыли написать troll mode on/troll mode off в своём сообщении.

Нет. Наверное, Вы всё-таки не понимаете, какой вопрос во всём этом обсуждении — ключевой.

Release notes надо читать, а не "вспоминать". ;)

> Знаю, что раньше CTE использовали с учётом того, что она материализуется.

Да, кто так делал (хинтовал) — теперь "поплатится".
"Удивительно", что зачастую это будут те же люди, которые любят говорить, что знают, что такое hints, и чем они опасны. ;)

Так выберите подходящие статусы на стороне приложения.
Вы же где-то храните исходные данные для when s.status = 'exists' then 'Существует', вот и фильтруйте этот список соответствий, чтобы получить status IN ('exists', 'deleting'). Оно работать на порядки быстрее будет.

> А Вы уже прочитали https://t.me/pgsql/291702 ?

Нет, но прочитал сейчас. Невчитывался, но вероятно вы про эту ссылку хотите сказать https://www.mdeditor.tw/pl/2cBB
Вот по этой ссылке и по ссылке http://www.lmdb.tech/bench/inmem/large.html вот такие вот фразы:

After the data is loaded a readwhilewriting test is run multiple times in succession. The number of reader threads is set to 1, 2, 4, 8, 16, 32, and 64 threads for each successive run. (There is always only a single writer.) All of the threads operate on randomly selected records in the database. The writer performs updates to existing records;

After the data is loaded a "readwhilewriting" test is run using 16 reader threads and one writer. All of the threads operate on randomly selected records in the database. The writer performs updates to existing records

Я больше не хочу это комментировать, два раза уже писал. Если кратко, то паттерн не тот.

> Откуда это утверждение?

Это моё утверждение, т.е. его сказал/написал я. Подтверждать не буду (т.е. не буду искать в сети статистику). Конечно же существуют такие нагрузки, где подавляющее большинство записей (Big Data), но моё ЛИЧНОЕ мнение такое, что люди в основном сохраняют данные, чтобы их читать, т.е. если вы сохранили байт и прочитали его <= 1 раза, то это не естественно как-то.

> Типичный смартфон, ага.

Не хорошо вначале давать одну ссылку, а потом комментировать, высмеивая, по другой.
Свой комментарий я давал основывясь на прочитанной прошлой статье и это утверждение я сделал по следующей причине: LMDB даёт хорошую производительность, стабильный размер данных под нагрузкой и небольшой load time.
На всякий случай напишу, что я не имел ввиду:
1. Не имел ввиду, что это самый лучший кандидат для смартфонов. Это лучший из тех, кто там есть. Я бы ещё с sqlite сравнил, если уж говорить про смартфоны.
2. Не имел ввиду, что LMDB не подойдёт куда-то ещё, кроме смартфонов.

Вообще не знаю, зачем я написал фразу про смартфоны. Наверное, чтобы дать понять, для кого та статья могла быть полезна.

> Вы всё-таки не понимаете, какой вопрос во всём этом обсуждении — ключевой.

Хорошо, напишите прямо или ещё раз.

И всё-таки Вы хитрый. Вначале кидаете ссылочку, "поднимаете бурю", а потом когда все укажут на понятный недостаток кидаете другую. Нельзя было сразу миновать этот шаг?

After the data is loaded a readwhilewriting test is run multiple times in succession. The number of reader threads is set to 1, 2, 4, 8, 16, 32, and 64 threads for each successive run. (There is always only a single writer.) All of the threads operate on randomly selected records in the database. The writer performs updates to existing records;

After the data is loaded a "readwhilewriting" test is run using 16 reader threads and one writer. All of the threads operate on randomly selected records in the database. The writer performs updates to existing records

> Я больше не хочу это комментировать, два раза уже писал. Если кратко, то паттерн не тот.

Значит, Вы не поняли то, что я Вам пытаюсь донести. :(
Да, "паттерн не тот", но с "тем" (когда записывается и читается "последовательно", который я тоже считаю малореальным) b-tree просто "растопчет" LSM — посмотрите хотя тот thread, на который ссылался Константин. Т.е. даже в его benchmarks LSM там проигрывает, насколько я помню.

> Подтверждать не буду (т.е. не буду искать в сети статистику).

Ну так а это и есть ключевой вопрос!
Т.е. именно от распространённых нагрузок зависит то, стоит ли использовать b-tree, или LSM, или hash (и т.д. и т.п.) или нет.

> если вы сохранили байт и прочитали его <= 1 раза, то это не естественно как-то.

Хмм... разве я такое где-то писал?

> Не хорошо вначале давать одну ссылку, а потом комментировать, высмеивая, по другой.

Хмм... я ожидал, что Вы прочитаете по внутренней ссылке то, что явно относится к тому, что Вы утверждаете.
И меня удивило, что Вы этого не сделали, вот и всё.

> Я бы ещё с sqlite сравнил, если уж говорить про смартфоны.

Spoiler: sqlite "с треском" провалится в сравнении с LMDB (но не потому, что он "плохой", а потому, что LMDB — это b-tree и ничего больше, а вот sqlite — более-менее полноценный SQL/RDBMS движок). Т.е. ссылку я давал не для сравнения продуктов, а для сравнения технологий.

> Хорошо, напишите прямо или ещё раз.

Написал выше.

> Вначале кидаете ссылочку, "поднимаете бурю", а потом когда все укажут на понятный недостаток кидаете другую.

Что-что?! Это разные нагрузки, и ссылки разные — они показывают, что b-tree трудно "победить" как в той, так и в другой ситуации! Какой ещё "понятный недостаток"?

> посмотрите хотя тот thread, на который ссылался Константин

Да, в планах. Он слишком длинный.

> Хмм... разве я такое где-то писал?

Вы писали, что вам неочевидно, что обычно чтение преобладает над записью. Как я понял, вы это под сомнение поставили.

> sqlite "с треском" провалится в сравнении с LMDB

Видимо ещё одну ссылку надо дать тем, кому это интересно.

> Написал выше.

Не знаю, правильно ли я понял, но, видимо, речь про то, что в том случае, который идеальный по моему мнению для LSM, LSM не сильно лучше B-Tree (ну не хуже же??? иначе большинство статей про это - ложь).

> Вы писали, что вам неочевидно, что обычно чтение преобладает над записью.

Нет, этого я не писал. Если писал — процитируйте. ;)

Писал я вот что:

> Может быть, разработчики других general-purpose RDBMS кардинально ошибаются, когда считают этот случай [очень] редким (и, соответственно, не используют LSM trees для on-disk indexes)? Мне он тоже кажется очень редким, но уверенности у меня нет.
» Но есть use case, на котором оно однозначно и убедительно выигрывает вставки случайных ключей в большую таблицу, с запасом не влезающую в память.
> Коллеги, это редкий случай, как вам кажется?

Вам лично как кажется?

> Видимо ещё одну ссылку надо дать тем, кому это интересно.

Тем, кому это интересно, надо поискать самостоятельно (мне в данный момент — нет, например). ;)

всем привет.
общий вопрос по проектированию. есть сущность карточки. есть 2 независимых списка пользователей. каждый со своим набором атрибутом. типом идентификаторов пользователей является uuid. пользователи не удаляются из таблицы никогда. карточку может создать пользователь из любого списка.
как правильней связать карточки и пользователей?
1) в карточке завести одно поле для айдишника одного из списков. нет внешних ключей и пользователь определяется на стороне приложения
2) в карточке создать поле для каждого списка пользователей. можно связать внешними ключами

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

а почему списки независимы?

объединять надо пользователей в одну сущность

Если это два ВИДА пользователей, надо применять наследование (отношение подкатерогии) и выделять общего предка пользователей двух типов, переносить туда общие атрибуты из обоих типов.

И к этому общему предку и привязывать карточки.

один список это прям пользователи с фио и пр., а второй некие автоматизированные системы - внешние апи. поля вообще никак не пересекаются

своди в один список, разделай правами доступа

или флагами на юзерах