для отчета, а отчеты формируются за какой то период из этих данных. Так как их много запрос отваливается и таймаут. Вопрос, уместно ли создать вьюшку(кэшировать их) для данных например за 2020год и формировать отчет из них?
почитайте про matirial view
А чего индекс не?
Эффективнее всего «порезать» таблицу на партиции.
180 млн и партиции? Меня терзают смутные сомнения в эффективности сего действа.
\d <tablename> + EXPLAIN (ANALIZE,BUFFERS) на тормозящих запросах - ну совсем не помешает.
180 млн это слишком много или слишком мало для партиций?
Сто восемьдесят миллионов каких записей? Сколько их прибавляется в единицу времени?
Без планов запросов я не готов дать ответ.
И опачки! Оказывается, что всё-таки надо сначала на структуру таблицы посмотреть.
А можно организовать хранение и не компостировать больше мозг.
В смысле организовать хранение?
В самом прямом.
в день примерно 30к записей, в теч полгода должно увеличиться в 2-2,5 раз, полей 22. По объему записей и структуры, таких таблиц 3 штук. Так как железа хорошие, пока проблем сейчас нет, корме отчетов, где скрипт долго отрабатывает из-за запросов с джойнами и объема данных.
Лучше бы Вы показали версию PostgreSQL, \d и \dt+ этой таблицы, и пару "типичных" запросов с их планами...
Если join не сложные и по вторичным ключам то все должно нормально отрабатывать, думаю стоит посмотреть на планы запросов и подумать насчёт индексов, записей не так много. У меня 300к в день прилетает и все норм, 27 полей и различные группировки.
Обсуждают сегодня