Так а как сделать для маленького количества непрочитанных сообщений(к примеру, < 1000)  - 100% счетчик, а для большого (1 миллион) - не 100%?

Count

Один раз при загрузке клиента, далее если push считаем там

Так, например, с ограничением (чтобы показывать что-то вроде "более 1000 непрочитанных"):

SELECT COUNT(*)
  FROM (
       SELECT 1
         FROM a_table AS cl
        WHERE id > 12312983
        LIMIT 1001 -- или сколько нужно
       ) AS nq

А, нет, подождите, не так прочитал вопрос.

Соглашусь, что отображать количество больше 1000 - бессмысленно, так как это никто читать не будет

А для на самом деле заданного вопроса есть следующий трюк, например (точность может быть низкая, сразу предупреждаю):

CREATE OR REPLACE FUNCTION public.count_estimate(query text)
 RETURNS bigint
 LANGUAGE plpgsql
 STRICT
AS $function$
DECLARE
rec   record;
rows  bigint;
BEGIN
  FOR rec IN EXECUTE 'EXPLAIN ' || query LOOP
    rows := substring(rec."QUERY PLAN" FROM ' rows=([[:digit:]]+)');
    EXIT WHEN rows IS NOT NULL;
  END LOOP;
  RETURN rows;
END;
$function$;

SELECT count_estimate('SELECT 1 FROM campaign_logs AS cl WHERE id > 15000000');
 count_estimate 
----------------
        1997888

SELECT COUNT(*) FROM campaign_logs AS cl WHERE id > 15000000;
  count  
---------
 1990000

А производительность?

Если у вас появятся чаты примеры которых вы привели, вы будете по-любому использовать что то вроде CitusDB или подобного на основе PostgreSQL, там буде с большими чатами на отельной ноде попроще😉

Я понимаю. Это просто интерес

А это практически мгновенно работает (независимо от условий) — тут же просто происходит "заглядывание" в статистику (так что, "теоретически" это зависит от stats. target, а практически вряд ли удастся измерить какую-то разницу, как мне кажется).

Ярослав подсказал хорошую идею с 1000+. Отображать точное количество не имеет смысла после этой цифры, так как маловероятно, что кто-то будет читать больше 1000 сообщений

Хм вот и база телеграмм не справилась))))
Хороший вариант. но промахиваться сильно будет при учете нагрузки и настроек статистики по таблице по умолчанию - шаманнить надо

Будет промахиваться, конечно (я сразу предупредил). ;)
Причём для типичной для таблиц сообщений нагрузки — куда сильнее, чем "в среднем по больнице".

Ага, с учётом условий по пользователю и чату вообще сильно шаманить,
При этом три bigint в индексе в памяти не так и много.
Ну да ладно спать

Ребята, а если я буду делать select с удаленного сервера на локальный в csv файл
какие ресурсы удаленного сервера будут задействованы?
Таблица 30 гб, надо ее сохранить локально, но свободной физ памяти на удаленном сервера 10гб, оперативы 16
По ощущениям оно долго собирает данные кудато в буфер, потому что файл не наполняется. Где этот буфер и сколько его надо для такой таблицы?

Максим, сделайте для начала SELECT from table limit 1000 в csv, чтобы проверить, что принципиально способ работает. Потом увеличьте до LIMIT 100000 и посмотрите, сколько времени заняло и какой ресурс тратится

С ходу идей никаких нет, должно работать через psql \copy

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

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

Спасибо, вроде работает, но да, есть падения ssh и прерывается выгрузка

Привет. Есть ли где-то описание того, что показывает каждый график в Grafana при использовании Pgwatch2? Часто одного названия графика недостаточно, чтобы понять, что он показывает.