Например, SELECT point,date FROM Inc WHERE point,date NOT IN( SELECT point,date FROM out)

where (point, date) In ( select (point, date) from ...

это если уж совсем надо ин

а так where existis (select null from out o where o.date = i.date ...

а так where existis (select null from out o where o.date = i.date ...

просто exists(select from

select; синтаксически корректное выражение

select; синтаксически корректное выражение

это вроде только на PG?

ну у нас и чатик про PG

Примените к tsvector’у unnest

Это даёт все лексем с позициями, а я ищу позиции именно найденных лексем. Что-то вроде ts_headline, только в виде массива позиций

Это даёт все лексем с позициями, а я ищу позиции именно найденных лексем. Что-то вроде ts_headline, только в виде массива позиций

А покажите пример, не совсем понятно, что вы хотите получить по итогу

unnest для ts_vector any unnest для ts_query

Это даёт все лексем с позициями, а я ищу позиции именно найденных лексем. Что-то вроде ts_headline, только в виде массива позиций

Вы можете разложить tsvectot через unnest и пересечь с ключами из tsquery, например. Но я не понимаю, что вы решаете за задачу

Кстати, если использовать rum вместо gin, то можно не держать в таблице tsvector, так как rum не требует recheck. Может, этот вариант будет добрее и не нужно будет раскладывать tsvector, а просто находить нужные кортежи из таблицы?

Вы можете разложить tsvectot через unnest и пересечь с ключами из tsquery, например. Но я не понимаю, что вы решаете за задачу

Я хочу определить, в каком именно месте документа сработал запрос. То есть из запроса вида "select 'cat:1 hate:2 dog:3':tsvector @@ 'hate&dog':tsquery" я хочу получить не "t", а "{2, 3}". Да, можно пересечь отдельные лексемы с tsquery , но это сработает только в случае односложных tsquery.

Я хочу определить, в каком именно месте документа сработал запрос. То есть из запроса вида "select 'cat:1 hate:2 dog:3':tsvector @@ 'hate&dog':tsquery" я хочу получить не "t", а "{2, 3}". Да, можно пересечь отдельные лексемы с tsquery , но это сработает только в случае односложных tsquery.

Я на вскидку не помню как разложить tsquery на лексемы. Если не подскажут вам, часа через три попробую поэкспериментировать

Если так сделать, то... Сразу же уволят!

обоснуйте пожалуйста :)

<БАБУШКА_MODE> Меня одного начинает бить мелкая дрожь от вопросов, содержащих словосочетание: "а можно сделать" ? :) </БАБУШКА_MODE>

<БАБУШКА_MODE> Меня одного начинает бить мелкая дрожь от вопросов, содержащих словосочетание: "а можно сделать" ? :) </БАБУШКА_MODE>

правильный ответ "разрешаю"

а я вчерашний вечер провёл за чтением пейпера про эволюцию, чего и вам желаю https://arxiv.org/pdf/1803.03453v1.pdf там много примеров про то, что бывает, если забыть дописать все условия в where

правильный ответ "разрешаю"

Ой есть хорошая шутка по этому поводу из личного опыта ) http://ps.tmpc.ru/672377062030 содержит мат

Ой есть хорошая шутка по этому поводу из личного опыта ) http://ps.tmpc.ru/672377062030 содержит мат

Не, я в другой армии служил, у нас более нейтральный ответ на "можно" был: можно Машку за ляжку, козу на возу, а у нас разрешите!

Зато запоминается с 1й попытки )

Привет всем есть люди которые работали с вк api

1800 человек в чате

ААААА

??

Коллеги, занимаюсь секционированием забиксовых таблиц

и вот что придумал

разбить history по месяцам

через наследование и check по месяцу от unixtime

в связи с чем вопрос

сильно будет тупить добавление в таблицу при check месяц(дата(unixtime)) ?

или... надо посмотреть есть ли функция, получающая месяц от unixtime!

тебе нужен настоящий месяц или месяцеподобный интервал?

можно просто порезать по 86400*365/12=2628000 секунд

Мне нужно разнести в разные таблы данные с юникстаймом по месяцам

Коллеги, занимаюсь секционированием забиксовых таблиц

А зачем, если не секрет? А для работы с unix time есть вроде только to_timestamp()...

разбить history по месяцам

По месяцам плохо

Я выше писал - норм по itemid

Вы соберите в badger запросы - поймёте, что даты вам ничем не помогут

А зачем, если не секрет? А для работы с unix time есть вроде только to_timestamp()...

а потому что history разрослась до 100ГБ

Точнее в history обычно хранится меньше месяца

Старые данные в trends

и их тоже

а потому что history разрослась до 100ГБ

И что? Партиционирование-то тут причём?

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

эти 4 варианта не понравились? https://www.zabbix.org/wiki/Main_Page

хорошая ссылка

а по конкретнее?

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

Партиционирование почти никогда не прибавляет производительности (по сравнению с индексацией), а вот отнимает —- запросто. Соответственно, предлагаю разобраться с запросами и индексировать.

это общая фраза

Партиционирование почти никогда не прибавляет производительности (по сравнению с индексацией), а вот отнимает —- запросто. Соответственно, предлагаю разобраться с запросами и индексировать.

Это postgres такой плохой или архитектура данных?

а вот документация postgrespro говорит об обратном

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

в мускуле прибавило, на некоторых таблицах даже на дневные партиции перешли

в ПГ тоже прибавляет

что вам поконкретнее надо? гляньте 4 варианта партицирования может что-то подойдет вам, хотя бы https://www.zabbix.org/wiki/Docs/howto/zabbix2_postgresql_autopartitioning

просто не хочу тупо по хуту делать, а с осознанием предмета

Это postgres такой плохой или архитектура данных?

Наоборот, если где-то _помогает_ то это СУБД —- "такая плохая", внезапно. :)

в ПГ тоже прибавляет

Ну вы же не измеряли по сравнению с индексацией, сознайтесь.

я верю документации ;)

например вот https://postgrespro.ru/docs/postgrespro/9.6/ddl-partitioning

Наоборот, если где-то _помогает_ то это СУБД —- "такая плохая", внезапно. :)

Мои задачи очень ускоряет partition-wise join, partition pruning и range-hash partitioning.

речь не про ваши задачи, а о заббиксе =)

Ну вы же не измеряли по сравнению с индексацией, сознайтесь.

Я секционировал pg_pathman. По itemid, таблицы history и trends. Снижает нагрузку за счёт быстрого housekeeping и автовакуума

я верю документации ;)

В документации много чего написано... "интересного". ;) Вот цитата оттуда, кстати: "Секционирование может сыграть роль ведущих столбцов в индексах" И на этом, по большому счёту, всё. Т.е. многие случаи ускорения связаны с seqscan-ами и т.п.

Я секционировал pg_pathman. По itemid, таблицы history и trends. Снижает нагрузку за счёт быстрого housekeeping и автовакуума

А вот это, безусловно, важно. И в этом и есть основной смысл партиционирования.

Нагрузка точнее - та же - но растянута во времени. Что повышает отзывчивость вэб интерфейса до 20 раз

Я секционировал pg_pathman. По itemid, таблицы history и trends. Снижает нагрузку за счёт быстрого housekeeping и автовакуума

Если бы секционировали по времени, то пылесос вообще можно отключить наверное. По большей части именно он и грузит систему вроде)

Если бы секционировали по времени, то пылесос вообще можно отключить наверное. По большей части именно он и грузит систему вроде)

А представьте вам нужен график за год?

Хранить партиции за год

Это 1 или 2 item который будет перебирать все партиции

Петр, я пробовал по времени

Пылесоса это не отменяет

Я бы вообще от него избавился, вся нагрузка от него

Потому, что housekeeper все равно чистит

Я бы вообще от него избавился, вся нагрузка от него

Там много обновлений

что вам поконкретнее надо? гляньте 4 варианта партицирования может что-то подойдет вам, хотя бы https://www.zabbix.org/wiki/Docs/howto/zabbix2_postgresql_autopartitioning

Первая же строка из ссылок которые вы порекомендовали. ;) Main culprit of slow and long Housekeeping process is usually the size of several tables, history, history_uint, trends and trends_uint. Overall performance is significantly improved by using PostgreSQL table partitioning (inheritance) model and splitting these tables on monthly basis.

Т.е. я рою в правильном направлении

Михаил, раз вам все равно рыть. Давайте сделаем замеры?

В документации много чего написано... "интересного". ;) Вот цитата оттуда, кстати: "Секционирование может сыграть роль ведущих столбцов в индексах" И на этом, по большому счёту, всё. Т.е. многие случаи ускорения связаны с seqscan-ами и т.п.

что быстрее: поиск по индексу в таблице из 100млн. записей или поиск по аналогичному индексу в таблице с 10млн записей?

Сначала без секционирования график за пару дней. Потом разбейте по времени (но я бы на вашем месте поглядел свойства элементов данных. Там есть время хранения значения и время хранения изменений)... Снял график за пару дней. А потом по itemid и тоже снял график

Так сказать ударим практикой по теории

что быстрее: поиск по индексу в таблице из 100млн. записей или поиск по аналогичному индексу в таблице с 10млн записей?

Какой "поиск по индексу" конкретно? Выборка одного значения / диапазона? Или полное сканирование?

Какой "поиск по индексу" конкретно? Выборка одного значения / диапазона? Или полное сканирование?

Диапазон там

Диапазон там

Тогда почти одинаково. А вот контрвопрос: Что быстрее: планирование запрос по обычной таблице или по 50-и партициям?

Тогда почти одинаково. А вот контрвопрос: Что быстрее: планирование запрос по обычной таблице или по 50-и партициям?

Вы имеете ввиду нативное секционирование?

Вы имеете ввиду нативное секционирование?

Неважно.

У pathman патриция выбирается вроде как другим способом

Так сказать ударим практикой по теории

я бы с удовольствием. Но нет такой роскоши,к сожалению. Потому и обратился за советом.

У pathman патриция выбирается вроде как другим способом

Да, другим. Так он что, выбирает партции быстрее, чем планируется запрос по несекционированной таблице?

Фактически задача разбивается на 2 - выбор секции и планирование запроса по 1 секции

или по нескольким секциям...

дропать данные партициями кстати тоже быстрее, чем удалять строки по условию, что важно для заббикса (но это не стандартный режим работы будет и придётся делать руками)

а дропать по условию из меньшей по размеру таблицы? имхо это тоже быстрее :)

а дропать по условию из меньшей по размеру таблицы? имхо это тоже быстрее :)

Нет, имеется в виду, что вы просто делаете DROP TABLE для секции, и это гораздо быстрее.

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

вывод - мелко нарезать таблы :)