Проблема при использования pg_varables в PostgeSQL 18, приводящая к ошибкам работы с памятью и искажением данных. В публикации описан способ решения проблемы.

PostgreSQL поддерживает так называемые диапазонные типы данных (range). Не буду переписывать документацию, а лишь укажу, что в этой статье мультидиапазонные типы (multirange) я затрагивать не буду, а остановлюсь для примера только на daterange. Причем на его частном случае, когда в рамках одного ключа допускаются исключительно непересекающиеся диапазоны дат.

Можно было купить готовый модуль, несмотря на его совершенно конскую стоимость в 6-7 тыс. рублей. Однако он не предоставлял наиболее востребованную для меня функциональность: не позволял открывать ворота автоматически "из коробки" при приближении к своему участку на автомобиле. Ну и, естественно, экономия на порядок тоже сыграла не последнюю роль.

Был выбран следующий способ реализации основной задачи: WiFi модуль в автомобиле пытается зарегистрироваться на домашней точке доступа. Если ему это удается - проверяется уровень сигнала. Если уровень сигнала слабый - значит приближаемся к участку и надо подать команду WiFi модулю на автоматике ворот на открытие. Если сигнал сильный - мы уже на участке и ничего делать не надо. Дополнительная функциональность - управление воротами по WiFi через веб-интерфейс, в том числе и с мобильного телефона.

Если при выезде с участка руки свободны и можно заранее открыть ворота со штатного пульта, то при подъезде к участку нащупывать кнопку на пульте отвлекаясь от дороги - не только не удобно, но еще и опасно. При этом ворота открываются относительно медленно и если нажимать кнопку пульта уже подъехав к воротам, то приходится ждать несколько секунд, пока ворота откроются.

Иногда перед разработчиком, аналитиком или даже бизнес-пользователем встает задача выполнить какие-то финансовые расчеты, соблюдая два строгих требования. Во-первых, даже для миллиардных сумм необходимо обеспечить точность до копейки, во-вторых, перекрестные итоги тоже должны сходиться до копейки.

Новый Год уже совсем на носу, а значит нужен свежий производственный календарь в базе данных PostgreSQL. Но как совершенно обленившийся IT-шник, заводить его руками не хочется. Хочется, чтобы вызовом одной функции он сразу появился. Ну а уж из этой функции можно его сохранить в табличку и спокойно использовать до следующего Нового Года. А тогда опять просто вызвать вызвать функцию и с чистой совестью отрапортовать о выполненной работе. Цель статьи - показать возможности COPY ... FROM PROGRAM и простейшие приемы парсинга XML в PostgreSQL.

Несмотря на избитость темы и многочисленные рекомендации избегать OR в выражениях WHERE/ON SQL запросов, жизнь вносит свои коррективы. Иногда сама постановка задачи подразумевает необходимость использовать OR. Я не собираюсь здесь рассматривать простые случаи, а сразу возьму быка за рога и рассмотрю случай, когда OR должно привести к двум разным выборкам по разным индексам одной и той же таблицы.

После дембеля в ноябре 1986 году я, вместо того чтобы посвятить всё свое свободное время алкоголю и женщинам, по инициативе отца и не без его помощи собрал ZX Spectrum. Вариант, "Львов", так я сам оттуда, а отец даже принимал косвенное участие в его проектировании. Как раз в те годы, когда я сапогами стучал в Советской Армии. Если более точно, то ремонтировал и обслуживал телеграфные аппараты на командном пункте ПВО страны. Это присказка.

Прошел год. На дворе январь 1988 года после успешно сданной сессии. Общежитие в Зеленограде. Народ играет на моем ZX Spectrum. А кто не играет, обсуждает, что неплохо бы его применять не только для игрушек, но и еще для чего-то полезного. Например, для курсовых и дипломных проектов. Так как про TR-DOS мы в эти годы даже не слышали, а подключение дисковода к ZX Spectrum казалось фантастикой, то обсуждались способы, как бы перенести файлы с кассеты на хотя бы на ДВК-2, чтобы оттуда их распечатать. Купить принтер тогда тоже казалось фантастикой.

В процессе этих фантастических дискуссий я вспоминаю о том, как ремонтировал телеграфные аппараты в армии и мечтательно заявляю:

-- Ну хотя бы рулонный телеграфный аппарат где-то надыбать! Хотя бы древний и убогий T-63, который я наизусть знаю и точно смогу починить.

И вдруг я слышу ответ от соседа по комнате:

-- Так у меня на практике, на городской АТС, целая груда списанных рулонных телеграфных аппаратов валяется.

Ура! Есть цель, есть средства, нужен план. Хотя зачем студентам план? "Чего тут думать! Трясти надо!" (с) - если кто не знает этот анекдот, могу потом найти его.

Исходя из того, что предыдущую статью не заминусовали и даже не сильно критиковали, попробую продолжить серию и поделиться с проблемами некоторых различий типов данных в MS SQL и PostgreSQL.

Сначала я думал просто перечислить наиболее распространенные проблемы, возникающие при переходе с MS SQL на PostgreSQL. Но решил, что просто перечисление будет мало информативным. Поэтому, пока ограничился наиболее частой проблемой, приводящей к деградации производительности при переходе с MS SQL на PostgreSQL. Если статья окажется нужной, то продолжу рассматривать остальные проблемы.

В некоторых случаях в DWH приходится периодическим заданием очищать таблицу и заполнять ее новыми актуальными данными. Например, раз в сутки. Если в таблице десятки или сотни тысяч строк, то это не проблема. А вот если миллиард - то уже точно проблема. Потому что каким бы способом ее не заполнять, но в течении достаточно длительного времени данные из этой таблицы не будут доступны пользователям. А если система должна быть доступна 24/7, то такие процессы начинают заметно ухудшать SLA.

Рассмотрим достаточно распространенную ситуацию. Имеется огромная таблица примерно следующей структуры:

Не буду вдаваться в подробности о том, откуда берутся миллионы временных серий и почему они умудряются изменяться еженедельно. Просто возникла задача еженедельно сделать прогноз на 2-8 недель по паре миллионов временных серий. Причем не просто прогноз, а с кроссвалидацией и выбором наиболее оптимальной модели (ARIMA, нейронная сеть, и т.п.).

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

Развернув очередной обратно разработчику Pull Request с поиском по аналитике, принимающей разные значения в разные промежутки времени, я решил на планерке обсудить этот вопрос. И был удивлен, что подавляющее большинство разработчиков не понимают, как эффективно искать на SQL в таких случаях. Погуглив, ради интереса, обнаружил, что этот вопрос как-то обходится стороной сообществом. В итоге решил написать статью, заодно ссылаясь на нее самому.

Сразу хочу уточнить, что речь идет именно об MS SQL, так как, например, в PostgreSQL уже есть диапазонные типы и виды индексов, позволяющие их индексировать.

Уже несколько лет назад я столкнулся с проблемой производительности 1С на PostgreSQL в некоторых запросах, которые на MS SQL выполнялись относительно быстро. Тогда же выяснилось, что в 99% случаев такие запросы можно оптимизировать так, что они начинают выполняться даже быстрее, чем на MS SQL, всего навсего добавлением нужных индексов во временные таблицы.

Однажды мне потребовалось забирать регулярно относительно большие объемы данных в MS SQL из PostgreSQL. Неожиданно выяснилось, что самый очевидный способ, через Linked Server на родные ODBC к PostgreSQL, очень медленный.

Мысли использовать автомобильные АКБ с UPS бродят по просторам интернета очень давно. Плюсы очевидны - стоимость ампер*часа автомобильных АКБ на порядок ниже, чем у родных АКБ для UPS. Многие даже успешно подключили. Я же только обобщил опыт из разных источников.