Можете пожалуйста описать более подробно как вы его подключили, с ссылками на aliexpress, какое питание, какой ESP и как правильно подключить. Сделайте пожалуйста несколько фото. Спасибо.
> А прикольно будет выглядеть этот триггер через пару лет с шестьюстами if-ами.
Согласен, в нем реально будут работать только верхние несколько строчек. Но в любом случае не рекомендуется держать 730 активных секций — postgresql сам начнет тормозить, неактивные секции можно/нужно отключать/удалять и триггер автоматом уменьшится, так что пользуйтесь с удовольствием.
Согласен, если данные приходят в случайном порядке, то функция будет лучше. Хотя тут свои «но» — нужно быть уверенным что таблица существует.
Обычно если делают секции по дате подразумевается что данные приходят последовательно. Судя по вашей структуре они у Вас тоже приходят последовательно :)
Позволю не согласится: при последовательной вставке данных новые данные попадают в первый IF и на этом триггер заканчивает работу. Также при сравнении не используется никакое преобразование данных.
второе — после запуска, не нужно никаких телодвижений, все будет работать без крона, не нужно думать о новых секциях, индексах
третье — это универсально, можно ставить на любую таблицу одной командой.
да, если у вас 365 секций, то в методе от zabbix, у Вас будет 365 rules. Каждое правило имеет больший overhead чем триггер. Грубо говоря это 365 триггеров vs 1 триггер с множеством условий.
Кстати Вы подсказали простую оптимизацию: расположить IF в обратном порядке, тогда условие о последних данных будет первым, и по сути для новых будет отрабатывать только первый IF.
Да проблема известная, ваше решение я видел, но по моему мнению оно похоже на полумеру, чтобы не терялась запись вы предлагаете вставлять тестовые записи заранее — конечно лучше, чем вручную секции добавлять, но уже не автомат. По поводу скорости вставки я имел ввиду скорость вставки не первой записи которая создает таблицу и копирует индексы, а регулярной вставки в уже созданные секции, при большом количестве секций от 100. В этом методе кроме вычисления имени секции в триггере (не используется) обрабатываются правила по 1 на каждую секцию в результате если даже все просто то на 100 секций нужно 101 действие для вставки 1 записи. В моем случае если секции уже созданы выполняется всего 1 триггер с 100 простыми IF ELSIF. Пример созданного триггера можете увидеть в статье
На мой взгляд не хватает нескольких вещей:
1. URL где произошла ошибка (не скрипта, а страницы)
2. По возможности захватить stack c вызовами
3. Ну и фильтры в админке
Спасибо, в целом удобно.
Не знаю какие процесы кроме логов, могут генерировать такой трафик (если рассмотривать типичные задачи). Логи логичней держать не в базе, а в каком нибуть nosql хранилище.
Ну а через десять лет мы просто изменим имя функциям с *_int2big на *_big2big128 и переведем все на еще большие цифры :)
Можете пожалуйста описать более подробно как вы его подключили, с ссылками на aliexpress, какое питание, какой ESP и как правильно подключить. Сделайте пожалуйста несколько фото. Спасибо.
Раньше не добивало до последней комнаты, теперь полный порядок :)
Согласен, в нем реально будут работать только верхние несколько строчек. Но в любом случае не рекомендуется держать 730 активных секций — postgresql сам начнет тормозить, неактивные секции можно/нужно отключать/удалять и триггер автоматом уменьшится, так что пользуйтесь с удовольствием.
Обычно если делают секции по дате подразумевается что данные приходят последовательно. Судя по вашей структуре они у Вас тоже приходят последовательно :)
второе — после запуска, не нужно никаких телодвижений, все будет работать без крона, не нужно думать о новых секциях, индексах
третье — это универсально, можно ставить на любую таблицу одной командой.
Кстати Вы подсказали простую оптимизацию: расположить IF в обратном порядке, тогда условие о последних данных будет первым, и по сути для новых будет отрабатывать только первый IF.
Конечно это работает, но если есть возможность обойтись без внешнего воздействия, лучше воспользоватся этим.
1. URL где произошла ошибка (не скрипта, а страницы)
2. По возможности захватить stack c вызовами
3. Ну и фильтры в админке
Спасибо, в целом удобно.
Ну а через десять лет мы просто изменим имя функциям с *_int2big на *_big2big128 и переведем все на еще большие цифры :)