На индексе - отнюдь не всегда. Просто по самой структуре индекса. Например, по таймстампу апдейта - такое поле всегда будет почти (потому что пользователей много и, следовательно, одновременно выполняющихся транзакций - в достатке и ассортименте) монотонно возрастающим (либо кто-нибудь полезет ручками это поле править, за что, в нормальной компании по руками схлопотать - как два пальТСа об асфальт), и вот как использовать место между двумя имеющимися значениями, если любое новое значение в лучшем случае попадает в какую-то ну очень маленькую эпсилон-окрестность хвоста последовательности? А удаление данных - где-нибудь посередине этих значений, и толку от того, что место освободилось?
И да, я на собесах, да и от коллег неоднократно слыхал про распухающие индексы при вполне себе адекватном поведении кучи. Т.е. объём данных, как ему положено болтается в каком-то вменяемом интервале (т.е. соотношение мертвых и живых записей - в пределах какой-то нормы), а вот индексы пухнут просто безбожно. И люди вопрошали: что делать? А я с подобным поведением, к сожалению, не сталкивался. И приведённое в предыдущем посте и вот эту вот расшифровку услыхал не вот уж давно.

> На индексе - отнюдь не всегда.

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

> и вот как использовать место между двумя имеющимися значениями

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

>  А удаление данных - где-нибудь посередине этих значений, и толку от того, что место освободилось?

Никакого, и я об этом и не писал. И b-tree так и должно себя вести в этих случаях (то, которое "из учебника", может сливать страницы, но PostgreSQL этого не делает).

> И да, я на собесах, да и от коллег неоднократно слыхал про распухающие индексы

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

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

"Столкнуться" очень просто, например:  https://dbfiddle.uk/?rdbms=postgres_12&fiddle=81c2bbdc4b5e20d5195a8fa1e3c6e35e ;)

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

что за тулза ? где рисуешь ?

сенкс

Использовать serial/bigserial или identity? Во всех случаях будет использован объект sequence.

В вашей схеме предполагается сквозная нумерация сообщений (и дырки в нумерации допустимы). Если вы хотите нумерацию сообщений с 1 в каждой теме, то в таблице message будет составной первичный ключ (conversation_id, message_number), но намучаетесь с заполнением message_number. Не советую так делать, сквозной номер лучше

Есть такой вот запрос (вот его часть)

     LEFT JOIN ( SELECT count(customer_grouped.customer_id) AS loan_count,
            customer_grouped.customer_id
           FROM ( SELECT statistic.customer_id,
                    statistic.loan_id
                   FROM loans.statistic
                  GROUP BY statistic.customer_id, statistic.loan_id) customer_grouped
          GROUP BY customer_grouped.customer_id) f5 ON so.customer_id = f5.customer_id

Как передать so.statistic_date в subquery, дабы вытащить каунт не всех записей, а только тех, что < so.statistic_date?

lateral можно использовать

so.statistic_date которой из записей so, которые попадут в строку итогового запроса вы хотите туда вытащить?

Немного не понял вопрос.

Это, видимо, потому что я не проснулся и херню всякую спрашываю.

Когда перечитал внимательнее -- моя интуицыя сказала мне, что и так должно работать. В смысле -- so.statistic_date если там есть поле statistic_date в таблицэ so.
Сейчас буду придумывать проверку.

А, всё, понял. Да, всё время путал FROM-list с SELECT.

Между прочим, это было бы куда проще читать если бы вы придумали минималный полный use case -- с описанием таблиц и полным запросом.

Я бы, наверное, попробовал прекратить заниматься вычислениями во FROM -- и отправил все группировки во внешний абсолютно SELECT.
И там ужэ считал count(DISTINCT loand_id).

ребята при подключении чтобы к разным базам распределить по условию
нужно haproxy или какой есть платный модуль для postgresl

pg bouncer?

по какому условию ? )

типа из разных Ip типа клиенты с разных странн