я могу данные в интефейсе забить

и показать результат)

Запросы через рабочий интерейс без проблем

Вот это можете, например (вызовет сканирование всего индекса, сразу предупреждаю)? SELECT MIN(cnt) AS mincnt, AVG(cnt) AS avgcnt, MAX(cnt) AS maxcnt FROM ( SELECT insideip, COUNT(*) AS cnt FROM flowlog GROUP BY insideip ) AS a

фигня получится

там несколько типов траафика

нужно еще фильтра по инсайду делать

там несколько типов траафика

Дело-то в том, что в присланных искуственных данных, на которых мы тут собираемся чего-то воспроизводить, результат примерно такой: 1, 1.0011, 3

ну вот смотрите. ПАТ: за 17:00 18:00 для одного аутсайда я нашел 170 записей

ну вот смотрите. ПАТ: за 17:00 18:00 для одного аутсайда я нашел 170 записей

Т.е. присланный script для генерации тестовых данных очень далёк от реальности. :(

В этот аут сайд попадает один инсайд. Для него в выборке есть 13 записей

за тот же период

т.е. данные от того, что хочешь найти будут сильно разниться

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

и 150

в заисимости от того как пользуются инетом

т.е. данные от того, что хочешь найти будут сильно разниться

Всё равно, к "максимум 3 записи по конкретному IP _за всю историю_" это даже не рядом. :(

я бы 3 приблизил к минимуму

микроблоки быстро протухают

но тут нужно в сетях немного разбираться, что бы это в голове уложилось)

по этому этим сервисом занялся я, а не кодеры наши)

я бы 3 приблизил к минимуму

В общем, @pensnarik это нужно учесть при генерации искусственных данных, по-хорошему.

по этому этим сервисом занялся я, а не кодеры наши)

А теперь, что касается запросов... они у Вас все примерно такого вида, как в примере? Если да, зачем Вам "CREATE INDEX active_idx ON public.flowlog USING btree (timeend);"?

А теперь, что касается запросов... они у Вас все примерно такого вида, как в примере? Если да, зачем Вам "CREATE INDEX active_idx ON public.flowlog USING btree (timeend);"?

выборка по timeend=0

иногда нужно

индекс по выражению не прижился

часто данные изменяются

иногда нужно

Почему не parital index, в таком случае (c WHERE timeend = 0)?

я его обозвал "по выражению"

не прижился

данные очень часто меняются

данные очень часто меняются

Ничего не понимаю... какая связь?

Ну пример: Открытый микроблок - это запись с timeend = 0. Когда микроблок закрывается, прилетает такая же, только с timeend = unixtime. Старая удаляется, на ее место вставляется вместо удаленной. Плюс еще не всегда прилетают данные о закрытии сессии (udp используется). И приходится их скриптом прогонять и закрывать по томуже принципу, но штамповать timeend = timestart + 12 часов

из-за частого перестроения данных все тупило

опытным путем пришел к тому, что интекс без выражения работает лучше

но это штука в целом нужна раз в месяц)

опытным путем пришел к тому, что интекс без выражения работает лучше

Вообще это как-то странно. А какой индекс-то был (и какая версия PostgreSQL)?

9.6 пг. Индекс был WHERE timeend = 0

9.6 пг. Индекс был WHERE timeend = 0

CREATE INDEX ... (какие поля?) WHERE timeend = 0? А что тупило-то? SELECT или UPDATE?

база вся

проц подрастал и io

через какое-то время

Я про свой запрос.

Ну вот попробовал я как-то партиционировать (на данных, "приближенных к реальным", но всего около 1M записей ;) ). Вышло 15 partitions по timestart (с неравномерным распределением, т.е. где-то 20K записей, где-то 100K). И вот запрос (без partitions): EXPLAIN (ANALYZE, BUFFERS) SELECT timestart, (max(timeend)) as timeend, insideip as internalip, outsideip as externalip, startport, endport FROM flowlog_real WHERE (timeend = 0 OR timeend >= 1512143634) — time_from AND timestart <= 1512146131 — time_to AND insideip = '10.128.26.23' GROUP BY timestart, insideip, outsideip, startport, endport ORDER BY timestart, insideip, outsideip; Даёт: Buffers: shared hit=32 Planning time: 0.721 ms Execution time: 0.413 ms Тогда как (из партиционированной таблицы): EXPLAIN (ANALYZE, BUFFERS) SELECT timestart, (max(timeend)) as timeend, insideip as internalip, outsideip as externalip, startport, endport FROM flowlog_real_partitioned WHERE (timeend = 0 OR timeend >= 1512143634) — time_from AND timestart <= 1512146131 — time_to AND insideip = '10.128.26.23' GROUP BY timestart, insideip, outsideip, startport, endport ORDER BY timestart, insideip, outsideip; Buffers: shared hit=98 Planning time: 5.362 ms Execution time: 1.141 ms

Это native (declarative) partitioning из 10-ки, pg_pathman у меня нет. Но никакого partition elimination не происходит, конечно.

соц опрос https://twitter.com/postgresmen/status/954069814317740032

соц опрос https://twitter.com/postgresmen/status/954069814317740032

твитор прилег

http://downrightnow.com/twitter

апперкейсники начили нажимать, догоняют

соц опрос https://twitter.com/postgresmen/status/954069814317740032

А что вообще значит CamelCase в этом опросе? Я вот пишу ключевые слова в UPPERCASE, а названия полей в snake_case —- это куда?

Это аппер, конечно. Речь про ключевые слова.

Это аппер, конечно. Речь про ключевые слова.

Ну а CamelCase тогда причём? Кто-то пишет "UpDate" или "And", что-ли? ;)