@Yaroslav_Schekin Добрый день, вы мне как-то помогали с оптимизацией запроса,

так вот он опять начинает подтормаживать, вернее даже не так, запрос выполняется секунд 10 но почему-то база ложится, я так понимаю это происходит когда такие запросы превышают какое-то число соединений, и php начинает выдавать ошибку по таймауту.
Вот я хочу узнать, сколько реально записей может быть в одной таблице для корректной и быстрой работы без использования партицирования или масштабирования базы данных?
Сейчас одно таблица содержит ~ 1148059136 записей, и это число растет на 3.5 миллиона каждые 24 часа, можешь дать пару советов?)

Так я не помню запрос и т.п. Покажите https://t.me/pgsql/476688, в общем.

там с этим проблемы, сейчас попробую найти нашу переписку

>сколько реально записей может быть в одной таблице для корректной и быстрой работы без использования партицирования или масштабирования базы данных? Миллиардов 300 примерно.

ахахахах, получается у меня запас еще в 99 миллиардов?)

На самом деле я отвечал "можэт" — в предположэнии минимальной таблицы. Так-то, если там записи по килобайту, и не тостятся особо — то это число падает до где-то 10 миллиардов. То есть всё от таблицы зависит. Максимальный размер таблицы (основного heap таблицы) — 32ТБ, чтобы корректно выполнялись всякие полнотабличные update — нужэн запас хотя бы вдвое. Так что, ну, когда таблица большэ 10 ТБ (основной heap таблицы, ну или toast-часть, если она большэ) — пора партицыонировать. И да... Скорость работы после этого почти всегда уменьшается.

update 3.5 миллионов только к одной таблице в сутки, таких таблиц 6 вроде как

> я так понимаю это происходит когда такие запросы превышают какое-то число соединений, и php начинает выдавать ошибку по таймауту. Ну, не превышайте это число соединений. Ну да, максимальный throughput (количество таких запросов в секунду) — зависит от того, сколько их параллельно выполняется. Поначалу (при двух-трёх-пяти и т.д.) соединениях — оно обычно растёт, поскольку растёт утилизацыя ядер за счёт параллелизма, уменьшаются простои I/O. Потом она выходит или на какой-то пик или на плато. Потом начинает снижаться из-за конкуренцыи за ресурсы, блокировки, вытеснения кого-то в своп и прочее такое. (в версиях до 12 это почти всегда был пик, потом было многое сделано, чтобы проблемы с блокировками были меньшэ — теперь это нередко плато). Естественно, что если не ограничивать число соединений — то при любой проблеме у вас будет всякий thrashing твориться, пропускная способность системы сильно упадёт. Проведите тэстирование, определите ваш максимум и ограничьте число воркеров — чтобы постгрес вам выдавал максимальную проивзодительность. (Потом, если надо — отмасштабируйте жэлезо или откорректируйте запросы, чтобы ваша максимальная проивзодительность решала вашы бизнес-задачи).

вес таблицы вместе с индексами на сколько я понял 777gb в данный момент, но если это очень мало, я не могу понять почему тогда обычный запрос по типу select ... from coin inner join table as t on t.id = t.coin_id where table.latest = true order coin.rate limit 100 offset 0 выпонялся быстно при 100 тысяч, а теперь более минуты? индексы по полям latest, coin_id where latest = true есть

Вы вроде не первый день тут https://t.me/pgsql/476688

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

Вписать запрос, там указано куда.

Но вообще — внимательно прочесть https://t.me/pgsql/303899 , понять что там написано. Это — набор данных, от которого можно начинать работать. Дажэ не в чятике, самому по себе — это что-то, от чего вообще можно отталкиваться.