Единственный Сис Админ в отпуске без связи.

Выводы я сделал, но от этого легче не стало

Выводы я сделал, но от этого легче не стало

Какие выводы? Вы проверили, что проблема не в чём-то подобном?

Какие выводы? Вы проверили, что проблема не в чём-то подобном?

Проверяем. Выводы в том что все кастомные настройки надо описывать

подскажите, как узнать установенную версию citus ?

подскажите, как узнать установенную версию citus ?

"SELECT * FROM pg_extension WHERE ... ", например.

"SELECT * FROM pg_extension WHERE ... ", например.

спасибо

Добрый день. Вопрос по postgis. Есть таблица с геометриями разных типов, нужно по ней искать пересечения. Как быть с коллекциями и чтобы работал индекс?Есть ли ещё варианты кроме добавления столбцов в таблицу с разбиением по типам?

а в чём проблема, что не работает из коробки?

St_intersects ругаеться на коллекцию, приходиться делить запрос на коллекции и на не коллекции. Коллекцию разбиваю st dump, но тогда не работает индекс

покажи запрос и ошибку

хммм, и правда

заведи тикет?

https://trac.osgeo.org/postgis/

@aleserche будет жить. Поприветствуем!

заведи тикет?

В описании st_intersect написано что не работает для коллекций если geometry

не будет тикета - не буду чинить :)

будет тикет - может, ещё в 2.5 протащить успеем

Vitaly смотри, почнинилось 17:20:02 [postgis_reg] > select ST_Intersects('POLYGON((0 0, 10 10, 3 5, 0 0))', 'GEOMETRYCOLLECTION(POINT(10 10), LINESTRING(0 0, 3 3))'); ┌───────────────┐ │ st_intersects │ ├───────────────┤ │ t │ └───────────────┘ (1 row) Time: 10,568 ms

Vitaly смотри, почнинилось 17:20:02 [postgis_reg] > select ST_Intersects('POLYGON((0 0, 10 10, 3 5, 0 0))', 'GEOMETRYCOLLECTION(POINT(10 10), LINESTRING(0 0, 3 3))'); ┌───────────────┐ │ st_intersects │ ├───────────────┤ │ t │ └───────────────┘ (1 row) Time: 10,568 ms

Ok :)

Ok :)

тикет? :)

тикет? :)

Сам себе уже напиши ;)

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

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

?

а ведь так и не сказал!)

и тикет не завел

и тикет не завел

Меня отпугнуло получение osgeo user :)

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

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

Отправил, жду мантру)

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

#4176

мне очень нравится фикс: https://github.com/postgis/postgis/pull/297/files#diff-978bce4984e620a04ff984c6c12d0776L2151

мне очень нравится фикс: https://github.com/postgis/postgis/pull/297/files#diff-978bce4984e620a04ff984c6c12d0776L2151

Отлично, спасибо. Получается надо и доку поправить)

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

Я писал про очередь уведомлений. А в чём вопрос?

Т.е. есть некий сервис, который слушает постгрес, сохраняет notify в очередь и отдает подключенным клиентам (приложению) из очереди?

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

Антиспам-бот)

Т.е. есть некий сервис, который слушает постгрес, сохраняет notify в очередь и отдает подключенным клиентам (приложению) из очереди?

Совершенно верно.

Т.е. есть некий сервис, который слушает постгрес, сохраняет notify в очередь и отдает подключенным клиентам (приложению) из очереди?

У меня есть в TODO небольшой проектишко pgnodis - PostgreSQL Notification Dispatcher. Суть в том, чтобы запускать произвольную команду ОС при наступлении события. Конечно же, я возьму для этого библиотеку Pgfe ?

Антиспам-бот)

Он обычно как-то позитивно настроен, приветствует. А тут прям суров... не в духе похоже был)

@Kazakbala будет жить. Поприветствуем!

Всем привет. Кто может подсказать с выбором решения. Есть таблица (на текущий момент 288млн записей) которая хранит историю изменений учётной единицы. Учётные единицы хранятся в отдельной таблице. Их 26млн. В среднем на 1 приходится 10 записей истории. Поиск по истории не ведётся, лишь просмотр всего списка и по родительскому айди (штрих код) Думаем оптимизировать путем деления на partition. И второй путь хранить все изменения в jsonb. При partition кол-во записей останется. При jsonb будет 1к1.

Посоветуйте какой из двух методов выбрать. Приклад на Java(hybernate)

какова исходная причина оптимизации?

какое ожидается изменение от партиционирования?

Из-за большого объёма данных медленнее стали работать выборки. Но не так критично.

Из-за большого объёма данных медленнее стали работать выборки. Но не так критично.

А индексировать не пробовали? И я всё же не совсем понял, какие запросы Вас интересуют, если "поиск по истории не ведётся" и "учётные единицы хранятся в отдельной таблице". :(

Завтра попробую скинуть план запроса (explain

На практике, в каких случаях можно применять partition?

Ищу подсказку - стоит ли игра свеч.

Ну например делить по месяцам удобно с точки зрения удаления.

А если записи никогда не удаляются?

Или когда большинство запросов всё равно считают относительно месяца.

Представьте что одно из условий в селекте стало физическим и вы добавляя его автоматически переходите к работе с меньшей таблицей с релевантными данными.

ну, это же в принципе сделает brin

Из таблицы селект в 90% только по общему ключу штрихкоду

Почитал комментарии на SO. -------- Partitions do NOT help here. Ok, here is the issue - partitions help you to search less data, but using an index with the segment_id as first field and filtering by this one - does exactly the same. Enough RAM and FAST IO are the only solution to fast reading in data. Partitions are basically a "delete one partition fast" thing - anything else gets at best a small gain.

На практике, в каких случаях можно применять partition?

Для maintenance, в основном. В плане производительности тоже можно выиграть, кстати, но нужно чётко понимать, почему, и использовать только в этих случаях. Потому что, в противном случае, потеряете много времени только ради того, чтобы стало хуже. :(

Почитал комментарии на SO. -------- Partitions do NOT help here. Ok, here is the issue - partitions help you to search less data, but using an index with the segment_id as first field and filtering by this one - does exactly the same. Enough RAM and FAST IO are the only solution to fast reading in data. Partitions are basically a "delete one partition fast" thing - anything else gets at best a small gain.

> but using an index with the segment_id as first field and filtering by this one - does exactly the same. Это, кстати, не совсем (или совсем не) верно.

Из-за большого объёма данных медленнее стали работать выборки. Но не так критично.

Возможно история хранится физически на разных областях диска. Можно посмотреть в сторону cluster.

Всем привет. Кто может подсказать с выбором решения. Есть таблица (на текущий момент 288млн записей) которая хранит историю изменений учётной единицы. Учётные единицы хранятся в отдельной таблице. Их 26млн. В среднем на 1 приходится 10 записей истории. Поиск по истории не ведётся, лишь просмотр всего списка и по родительскому айди (штрих код) Думаем оптимизировать путем деления на partition. И второй путь хранить все изменения в jsonb. При partition кол-во записей останется. При jsonb будет 1к1.

> Поиск по истории не ведётся, лишь просмотр всего списка и по родительскому айди (штрих код) Я один понял ровным счётом ничего из этой фразы?! о_О Кстати, если я что-то и понял, то партиционирование в данном конкретном случае надо делать по штрих-коду. Ну и да, индексы, что с ними?

Доброе утро, помогите, пожалуйста понять логику PG в части использования Index cond => \d+ model_oku Таблица "public.model_oku" Столбец | Тип | Модификаторы | Хранилище | Цель для статистики | Описание ---------------+------------------------+---------------------------------+-----------+---------------------+---------- year_month | character varying(10) | NOT NULL | extended | | code_supplier | character varying(25) | NOT NULL | extended | | account | character varying(25) | NOT NULL | extended | | house_code | character varying(25) | NOT NULL | extended | | unit_number | character varying(5) | DEFAULT NULL::character varying | extended | | service | character varying(255) | NOT NULL | extended | | charge | numeric(12,4) | NOT NULL DEFAULT 0 | main | | accident | numeric(12,4) | NOT NULL DEFAULT 0 | main | | underpayment | numeric(12,4) | NOT NULL DEFAULT 0 | main | | overpayments | numeric(12,4) | NOT NULL DEFAULT 0 | main | | facilities | numeric(12,4) | NOT NULL DEFAULT 0 | main | | subsidies | numeric(12,4) | NOT NULL DEFAULT 0 | main | | offered | numeric(12,4) | NOT NULL DEFAULT 0 | main | | paid | numeric(12,4) | NOT NULL DEFAULT 0 | main | | amount_debt | numeric(12,4) | NOT NULL DEFAULT 0 | main | | file_source | character varying(20) | NOT NULL | extended | | period_code | integer | NOT NULL | plain | | service_id | integer | | plain | | Индексы: "model_oku_account_idx" btree (account) "model_oku_file_source_idx" btree (file_source) "model_oku_period_code_idx" btree (period_code) "model_oku_service_id_period_code_idx" btree (service_id, period_code) "model_oku_year_month_idx" btree (year_month) Параметры: autovacuum_enabled=true => explain analyze SELECT MAX(period_code) AS code FROM model_oku WHERE account='1040349-Г1'; QUERY PLAN -------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Result (cost=414.88..414.89 rows=1 width=4) (actual time=1780.896..1780.896 rows=1 loops=1) InitPlan 1 (returns $0) -> Limit (cost=0.43..414.88 rows=1 width=4) (actual time=1780.893..1780.893 rows=0 loops=1) -> Index Scan Backward using model_oku_period_code_idx on model_oku (cost=0.43..903481.92 rows=2180 width=4) (actual time=1780.892..1780.892 rows=0 loops=1) Index Cond: (period_code IS NOT NULL) Filter: ((account)::text = '1040349-Г1'::text) Rows Removed by Filter: 6510952 Planning time: 0.211 ms Execution time: 1780.926 ms

т.е. для меня удивительно почему выбрано условие (period_code IS NOT NULL)

pg 9.6.9

чтобы исключить из перебора ветвь индекса с нуловым period_code

Т.к. наличие записи с пустым period_code имеет тот же результат, что и ее отсутствие

ну и в результате просматривается вся таблица

ну и в результате просматривается вся таблица

С виду, тут обычное дело — планировщик рискнул и... проиграл. :( Можете показать оценки (только rows из самого верхнего node) для: EXPLAIN SELECT * FROM model_oku; EXPLAIN SELECT * FROM model_oku WHERE account='1040349-Г1'; EXPLAIN SELECT DISTINCT peridod_code FROM model_oku; ?

С виду, тут обычное дело — планировщик рискнул и... проиграл. :( Можете показать оценки (только rows из самого верхнего node) для: EXPLAIN SELECT * FROM model_oku; EXPLAIN SELECT * FROM model_oku WHERE account='1040349-Г1'; EXPLAIN SELECT DISTINCT peridod_code FROM model_oku; ?

интересно какой логике следовал PG при выборе плана rows=6614295 rows=876 rows=6614295

ну и в результате просматривается вся таблица

вы думаете, без этого условия будет просматриваться не вся? смею предположить, что у вас по аккаунты селективность не очень

вобщем, вот этот - “model_oku_account_idx" btree (account) - индекс относительно бесполезный в вашем случае

интересно какой логике следовал PG при выборе плана rows=6614295 rows=876 rows=6614295

Вы уверены, что для последнего EXPLAIN SELECT DISTINCT period_code FROM model_oku; действительно 6614295? Т.е. на period_code мог бы быть уникальный индекс (так думает планировщик, если всё тут верно)? Вы делали VACUUM ANALYZE этой таблицы?

интересно какой логике следовал PG при выборе плана rows=6614295 rows=876 rows=6614295

Все логично, для выборки всех записей нужно выбрать все записи, для distinct тоже

Если без индекса

explain analyze SELECT MAX(period_code) AS code FROM model_oku; QUERY PLAN ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Result (cost=0.46..0.47 rows=1 width=4) (actual time=0.017..0.017 rows=1 loops=1) InitPlan 1 (returns $0) -> Limit (cost=0.43..0.46 rows=1 width=4) (actual time=0.015..0.015 rows=1 loops=1) -> Index Only Scan Backward using model_oku_period_code_idx on model_oku (cost=0.43..180232.60 rows=6614295 width=4) (actual time=0.015..0.015 rows=1 loops=1) Index Cond: (period_code IS NOT NULL) Heap Fetches: 0 Planning time: 0.098 ms Execution time: 0.033 ms

если запрос выше - регулярный, то делайте индекс по account и period_code

вобщем, вот этот - “model_oku_account_idx" btree (account) - индекс относительно бесполезный в вашем случае

С чего это? Вполне может быть подходящим.

explain analyze SELECT MAX(period_code) AS code FROM model_oku; QUERY PLAN ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Result (cost=0.46..0.47 rows=1 width=4) (actual time=0.017..0.017 rows=1 loops=1) InitPlan 1 (returns $0) -> Limit (cost=0.43..0.46 rows=1 width=4) (actual time=0.015..0.015 rows=1 loops=1) -> Index Only Scan Backward using model_oku_period_code_idx on model_oku (cost=0.43..180232.60 rows=6614295 width=4) (actual time=0.015..0.015 rows=1 loops=1) Index Cond: (period_code IS NOT NULL) Heap Fetches: 0 Planning time: 0.098 ms Execution time: 0.033 ms

Так это тот же самый план, который Вы уже показывали, нет? Вы бы лучше на мои вопросы ответили... ;)

Вы уверены, что для последнего EXPLAIN SELECT DISTINCT period_code FROM model_oku; действительно 6614295? Т.е. на period_code мог бы быть уникальный индекс (так думает планировщик, если всё тут верно)? Вы делали VACUUM ANALYZE этой таблицы?

нет не уверен, сделал vacuum analyze и для последнего выдало Result (cost=772.83..772.84 rows=1 width=4) (actual time=1875.500..1875.500 rows=1 loops=1)

а эксплейните такое

SELECT period_code AS code FROM model_oku WHERE account='1040349-Г1' ORDER BY 1 DESC LIMIT 1;

нет не уверен, сделал vacuum analyze и для последнего выдало Result (cost=772.83..772.84 rows=1 width=4) (actual time=1875.500..1875.500 rows=1 loops=1)

Знаете что... покажите все 4 explain-а полностью (и без ANALYZE, он тут не нужен). А то непонятно, откуда Вы вот это Result (cost=772.83..772.84 rows=1 width=4) вообще берёте. :( Лучше на paste site...

а эксплейните такое

Limit (cost=0.43..753.92 rows=1 width=4) (actual time=1679.578..1679.578 rows=0 loops=1) -> Index Scan Backward using model_oku_period_code_idx on model_oku (cost=0.43..643476.96 rows=854 width=4) (actual time=1679.576..1679.576 rows=0 loops=1) Filter: ((account)::text = '1040349-Г1'::text) Rows Removed by Filter: 6510952 Planning time: 0.134 ms Execution time: 1679.599 ms

Знаете что... покажите все 4 explain-а полностью (и без ANALYZE, он тут не нужен). А то непонятно, откуда Вы вот это Result (cost=772.83..772.84 rows=1 width=4) вообще берёте. :( Лучше на paste site...

+++

https://pastebin.com/9bLWfYep

select count(1) from (select distinct account from model_oku) _; возвращает 12234, по-моему нормальная селективность по account

https://pastebin.com/9bLWfYep

Спасибо, скоро посмотрю...

select count(1) from (select distinct account from model_oku) _; возвращает 12234, по-моему нормальная селективность по account

Вы бы уж тогда "EXPLAIN select distinct account from model_oku;" показали. В общем, дело не в том, каковы реальные оценки чего-либо для таблицы. Главное, что высчитывает планировщик (исходя из статистик).

Спасибо, скоро посмотрю...

Вам спасибо. если в запросе указан account которого нет в таблице и сам запрос выполняется относительно долго. но вот если поискать по account который в таблице есть, то запрос начинает работать за приемлемое время https://pastebin.com/rD1RYxJ5

Вы бы уж тогда "EXPLAIN select distinct account from model_oku;" показали. В общем, дело не в том, каковы реальные оценки чего-либо для таблицы. Главное, что высчитывает планировщик (исходя из статистик).

https://pastebin.com/f9Yaqurn

>>но вот если поискать по account который в таблице есть, то запрос начинает работать за приемлемое время Вы же понимаете, что это частный случай?