Всем привет! Подскажите, как получить количество записей в таблице, не

забивая память селектом?

Свою память?

И свою тоже ) Но вообще про оперативку...

Ты считаешь, что когда субд делает count, она все записи в оперативку считывает?

Втупил тут, сорян )) Тогда сопутствующий вопрос - если несколько сотен миллионов записей в таблице - насколько быстрым будет select count и есть ли что то более быстрое?

Just Google it

Если ты решил считать total для пагинатора, то так не надо

В некоторых случаях лучше промолчать.

а зачем? какая цель?

Думаете кто то тут умнее авторов оф доки?

У меня есть длительный фоновый процесс расчета и записи этих сотен миллионов, хотелось бы получать количество уже записанных на текущий момент.

Примерное значение есть кажется в pg_stat_all_tables. Может быть в другой системной вьюхе, но не суть. Ну и это действительно «примерное» число с кучей оговорок.

вот в нем и считайте

Есть и такой вариант. Но пока рассматриваю оба, смотрю как удобнее будет.

другого точного варианта нет. считать запросом - это боль причем бессмысленная

Если вы пишете данные в приложении, то ведь приложение знает, сколько оно данных в БД передало

Ок, спасиб

Да там с передачей этих данных немного геммор. Но раз вариант с count однозначно хуже - значит лучше этот геммор в аппе решить.

Считывает-считывает. Другой вопрос, что в памяти постгреса они не задержываются -- но вполне остаются занимать место в кэшэ ОС.

Есть разные методы оцэнки количества записей. Есть pg_stat_all_tables и pg_class -- из спецыально собираемой статистики, либо из autovacuum. Это, понятно, только для всей таблицы (и подвержэно некоторым систематическим ошыбкам). Есть возможность использовать TABLESAMPLE -- чтобы пройтись только по части таблицы. Наконец, можно настроить точный подсчёт -- триггером на insert/update/delete. Есть дажэ расшырение, которое что-то такое предлагает https://github.com/sraoss/pgsql-ivm

Спасиб

Вам надо прогресс операции мониторить? Тогда вот вам вариант околобесплатной передачи данной инфы: периодически (раз в N записей, подбирая N таким образом, чтобы эти записи генерились за 10+ секунд) выполняйте в сессии, в которой вставляете записи запрос set application_name = your_app_name: <NNN>'; где <NNN> - число обработанных записей. Затем просто в pg_stat_activity находите нужную сессию и считываете <NNN>.

Мы просто в базу пишем сколько записей обработано, каждые 10%

Да, такой вариант тоже смотрю, правда в отдельную таблу

Это хорошо работает только если не в одной транзакцыи всё пишэтся.

Ну обновлять сотни тысяч строк в одной транзакции это такое себе, человек отчёт час ждал а в итоге ошибка, не хорошо

Хмм, а если по бизнесу транзакция такая? Т.е. (рил стори) обновляем порядка 1 млн строк, загружая новые цены. Нужно, чтобы они вступили в действие все сразу. Загрузка «в лоб» в один поток занимает около 2ч. Городить дополнительный столбец «версия» в этой таблице (и, извините, ключ «текущая версия» в redis) который и переключать после завершения?

Цены должны иметь историчность

А они и имеют, кстати, исторически (sic!) реализовано, что хранится одна текущая в основной таблице + пачка старых в отдельной специальной таблице (собственно, эти таблицы за годы работы и составляют основной объём БД).

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

ну так грузите цены частями, если дата начала действия цены есть

Я позволю здесь себе тупой вопрос — а если никаких больше апдейтов, кроме таких заливок, в этой таблице не бывает, то сильно ли навредит (читателям) наша пишущая транзакция хотя бы и на 2ч? Дело даже еще вот чем облегчается — там и читателей-то особо нет, в этой таблице, кроме пакетной выгружалки цен раз в 15 минут в отдельную структуру (не спрашивайте), из которой их и читают потом все остальные потребители.

Ну кстати, в половине случаев просят залить «сегодня, чтобы вступило завтра», т.е. дата начала смысл имеет. И ставить её в некотором будущем. А если приспичило — пакетом перекинуть чуть раньше.

Если весь кластер только читают, помимо этих двух таблиц, то не навредит. В противном случае будет мешать работе autovacuum.

о чем и речь

В постгресе норм более-менее. Только невакуумированные записи (во всех таблицах) и блокировки (на запись, только в обновлённых таблицах) накапливаются, пока идёт транзакцыя. Чаще всего на миллион записей это не так страшно. И на полчаса задержка -- тожэ. Иногда бывает, что за минуты (десятки минут) какая-нибудь маленькая, но нагружэнная таблица в разы распухает и скорость меняется в худшую сторону.

И да, версии для цэн -- полезны, конечно. Как таковые, без учёта дажэ проблем СУБД.

фарма?