Партицирование может дать выигрыш если а) большинство запросов локальные, т.е. затрагивают тоько один партишин. б) используются вторичные индексы Первое вроде очевидно, второе - надо пояснить. Да, поиск в индексе с 10 млн записей быстрее чем поиск в индексе с 100млн. записей. Но не в 10 раз а в log(10). Тка что, если запросы делаются воссновном по какому-то относительно недавнему диапазаону времени, то эффекта от партицирования почти не будет. Но вот если задействованы вторичные индекы, по которым данные не упорядочены, и глобальный индекс целиком не влезает в память, а индекс на партишин -влезает, то тогда партицирвание может разогнать на порядок.

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

Во-первых, не в log(10), а (максимум!) в разницу логарифмов (по основанию в кол-во записей во внутреннем узле) от кол-ва записей в непартиционированнй и партиционированной таблицах. В данном примере с 10-100 это скорее всего... 0 (т.е. кол-во чтений одинаково). Во-вторых, что такое "вторичные индексы"? В-третьих, если запросы идут по многим партциям, фактически сканируя какие-то —- да, выигрыш будет, но за счёт seqscan-ов.

Извините, вы не из postgrespro часом? :)

Рискну спросить, а откуда такие глубокие познания?

Сколько у вас history хранит дней? У меня от 7 до 30 - в зависимости от элемента (uint - всегда 7 дней). Остальное в trends

т.е. грубо говоря, нужно дропнуть те таблицы, в которых записи старше 1.5 лет

У pg_pathman есть механизм поиска таких партиций )

это ко мне вопрос? :) если ко мне, то отвечу: имена патриций типа events_y2017m6, ну и т.д. Все таблицы наследуют events и создаются по необходимости по триггеру

о, ну кмк тут вообще не проблема - удаляйте от таблицы events_y2016m9 и ранее %)

ох, там что, тыщи старых кандидатов на удаление?.. да в экселе накидать эти "магические" числа да соединить в строчку )

ладно, придется писать процедуру и ронять прод :)

да хоть гуглшитс ?

а через generate_series кто сделает?

@tofghd по простому покажите SELECT count(*) FROM pg_tables WHERE tablename < 'events_y2017m' AND tablename LIKE 'events_y%'

жаль правда что месяц закодирован одной цифрой

выдает таблицы, никак не связанные с events

а если двумя?

17 таблиц всего, изи

Чегой-то у меня никак индексскана не получается, а хочется. :(

Чегой-то у меня никак индексскана не получается, а хочется. :(

народ, а вот такой вопрос: есть табличка логов: create table action_logs ( al_id bigserial primary key, action_ts timestamp, ... ) CREATE INDEX action_logs_action_ts_idx ON action_logs (action_ts); Дык вот, запрос select count(*) from action_logs where action_ts >= current_date - 7 вызывает bitmap index scan есть ли возможность заставить ПГ делать index scan?

какой work_mem?

256Мб

какую именно?

на 9.3 сейчас сделал select * from ssr_smeta_act where object_create_date > (now()::date - 7)::timestamp все ок

понизь рандом пейдж кост

Aggregate (cost=496940.19..496940.20 rows=1 width=4) (actual time=223.200..223.200 rows=1 loops=1) -> Bitmap Heap Scan on action_log (cost=20362.43..494220.89 rows=1087723 width=4) (actual time=69.911..155.283 rows=1086466 loops=1) Recheck Cond: (start >= (('now'::cstring)::date - 14)) -> Bitmap Index Scan on action_log_start_idx (cost=0.00..20090.49 rows=1087723 width=0) (actual time=68.147..68.147 rows=1086466 loops=1) Index Cond: (start >= (('now'::cstring)::date - 14)) Total runtime: 223.259 ms

постгрес же считает что будет дешевле

Yaroslav 9.3 я народ ввёл в заблуждение, было select count(pk) from table, а не select count(*) from table, по второму запросу вообще индекс оунли скан.

Yaroslav 9.3 я народ ввёл в заблуждение, было select count(pk) from table, а не select count(*) from table, по второму запросу вообще индекс оунли скан.

А * тут не влияет?

.

Дайте ченидь за индексы почитать

Всем привет! подскажите, пожалуйста, как можно удобно перетащить большое число файлов из xml в таблицы ? кейс - смигрировать репозиторий с liquibase в постгрю, чтобы можно было по id из databasechangelog явно понять какой запрос там на самом деле выполнялся

Pgloader?

Всем привет. Такой вопрос как лучше хранить список комментариев к товару ? В ячейке "comments" с типом jsonb или создать отделью таблицу под комментарии с внешним ключем ?

Pgloader?

Таблицу, если нет особых, веских причин.

А вообще плохо делать ячейку с типом jsonb, в которой лежит массив объектов в которых есть id и по ним обьеденять с другой таблицей ? Какие проблемы такая реализация может за собой нести ?

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

Спасибо большое за разъяснение