Только в достаточно специфичных случаях. И как это избежать я указал.
могут и другие проблемы быть
Тоже самое можно сказать не только про расширения, но и про сам PostgreSQL. В последнем обновлении от 13 ноября 2025 года в PostgreSQL 14-18 было исправлено почти по полсотни ошибки для каждой версии. А судя по принятым исправлениям ошибок в последующих commintfest, в следующем обновлении их будет столько же.
Следует понимать, что механизм вызова пользовательских функций, написанных на C, официально не менялся, примерно, с PostgreSQL 9.4. А обращений к БД pg_variables не требует.
Если Вы считаете, что произведенное мной тестирование недостаточно для Вашего планирования рисков, то проведите собственное.
Свой глобальный аллокатор нужен очень редко. До тех пор, пока нет возможности передать ему хотя бы пул, из которого хочется выделить память. На МК это было бы очень востребовано.
Можете оставаться при своей точке зрения. Это исключительно Ваши проблемы. В моей же сфере деятельности категорически недопустимо накладывать какие-то ограничения, непосредственно влияющие на результат выборки данных, если эти ограничения не были предварительно согласованы с заказчиком и документально зафиксированы.
который не уточнит эти граничные условия на основе имеющихся у него данных
Вот именно. Вы самостоятельно ввели ограничение на 15 дней нахождения основного средства на площадке, не удосужившись уточнить или согласовать это условие, хотя оно напрямую влияет на результат выборки.
Я сократил модель, так как построение btree_gist индекса на реальных объемах данных может занять часы. Но при увеличении объемов данных GIST будет ещё больше проигрывать, в чём можете убедиться.
Я бы расстался с разработчиком, который, как Вы, стал настаивать на том, что он вправе в задаче использовать какие-то ограничения, которых нет в постановке задачи.
Предлагаю на это закончить.
P.S. Немного о математике и семантике. "Сотни тысяч" - это может быть и 300 тысяч. "Около миллиона" - это может быть и 900 тыс. Дальше посчитаете?
Срок службы полувагонов в России составляет 20-30 лет. При этом следует учитывать, что в собственности у крупного оператора находится несколько десятков тысяч вагонов. Остальные вагоны под управлением - это вагоны сторонних операторов в краткосрочной аренде или по доверенности. Просто по той причине, что на станции погрузки может не быть собственных вагонов, а гнать туда порожняк может оказаться невыгодным. Отсюда и возникает большая текучка вагонов под управлением в конкретный момент времени.
В том-то и дело, что опираться при оптимизациях подобного рода имеет смысл именно на "прикладные" особенности распределения данных в конкретных условиях.
Еще раз, недопустимо опираться на особенности тестовых данных, которые не заявлены в постановке задачи. Это безответственно и опасно.
В данном случае, никто не давал гарантий, что нет основных средств, которые годами находятся на одной и той же площадке. Так же как никто не давал гарантий, что основных средств будет всегда 1000, а не миллион.
Как в статье - почему мы хотим отобрать аж целую треть объектов?
Потому что таковы бизнес требования.
Если интересно, то пример был взят максимальным упрощением реальной задачи. Основные средства - это вагоны, которых в конкретный момент под управлением может быть сотни тысяч. Суммарно же было под управлением за последние 20 лет - около миллиона. Под Дебальцево несколько составов стоят уже с 2014 года. А некоторые станции находятся настолько близко, что дискретизация границ периодов используется до минут, а не дней.
Во-первых, другого источника для этого расширения я не знаю. Во-вторых, с чего Вы взяли, что не работает? В статье я лишь указал, что следует сделать, чтобы избежать рисков, возникающих, если типы строковых констант явно не указываются.
В случае кольцевого буфера DMA UB неизбежен. Компилятор никак не может определить ни то, насколько этот буфер был DMA заполнен, ни то, были ли утеряны данные в этом буфере из-за перезаписывания.
Можно только своим кодом обрабатывать эти ситуации. В первом случае отслеживая значение следующего адреса регистра канала, а во втором, восстанавливая пропуски или перезапрашивая данные протоколом более высокого уровня.
А если не упрощать задачу, как сделал я в статье, а выполнять реальные бизнес требования, когда вместо дат - время с дискретностью до минуты, а этих основных средств - около 100 тысяч, если учитывать так же управляемые по доверенности?
Обновляешь битмапы раз в сутки батчем
Для примера, история дислокаций у нас занимает около двух терабайт. Не слишком ли неэффективно обновлять её каждые сутки? Особенно с учётом того, что оперативный доступ к ней требуется в режиме 24/7.
К тому же, каждая запись у нас не ограничена основным средством, площадкой и периодом, как в описанном очень упрощённом примере. А имеет еще более 70 аналитик, по которым требуется фильтрация или агрегация.
Проблему изменений требований для аналитики у нас замечательно решает CH. Но он не пригоден для оперативных отчетов, которым нужны актуальные и консистентные данные из оперативной ACID БД.
рост времени исполнения в зависимости от рамеров линейный
Зависимость времени выборки от размеров близка к линейной для BTree, но совсем не линейна для GIST.
Например, увеличим количество основных средств в 100 раз и сформируем таблицу не из 1.3 миллиона, а из 127 миллионов записей. Теперь так же выберем записи для каждого третьего основного средства на 1 января 2020 года, получив вместо 333 уже 33333 записей в выборке.
С использованием btree_gist:
Nested Loop (cost=0.42..86956.11 rows=29517 width=22) (actual time=2.204..1495.583 rows=33333.00 loops=1)
Buffers: shared hit=195120
-> Function Scan on generate_series g (cost=0.00..333.33 rows=33333 width=4) (actual time=2.128..4.126 rows=33333.00 loops=1)
-> Index Scan using tmp_asset_location_asset_period on tmp_asset_location a (cost=0.42..2.59 rows=1 width=22) (actual time=0.040..0.044 rows=1.00 loops=33333)
Index Cond: ((asset_id = g.n) AND (date_period @> '2020-01-01'::date))
Index Searches: 33333
Buffers: shared hit=195120
Planning Time: 0.149 ms
Execution Time: 1497.564 ms
И с использованием только BTree:
Nested Loop (cost=0.57..57672.79 rows=33333 width=22) (actual time=2.166..294.004 rows=33333.00 loops=1)
Buffers: shared hit=166665
-> Function Scan on generate_series g (cost=0.00..333.33 rows=33333 width=4) (actual time=2.119..3.976 rows=33333.00 loops=1)
-> Subquery Scan on a (cost=0.57..1.71 rows=1 width=22) (actual time=0.008..0.008 rows=1.00 loops=33333)
Filter: (upper(a.date_period) > '2020-01-01'::date)
Buffers: shared hit=166665
-> Limit (cost=0.57..1.70 rows=1 width=26) (actual time=0.008..0.008 rows=1.00 loops=33333)
Buffers: shared hit=166665
-> Index Scan Backward using tmp_asset_location_asset_date_period on tmp_asset_location t (cost=0.57..476.46 rows=422 width=26) (actual time=0.008..0.008 rows=1.00 loops=33333)
Index Cond: ((asset_id = g.n) AND (lower(date_period) <= '2020-01-01'::date))
Index Searches: 33333
Buffers: shared hit=166665
Planning Time: 0.135 ms
Execution Time: 296.121 ms
Как видно, при увеличении объемов данных в 100 раз, BTree действительно показал почти линейный прирост (296 мс против 3 мс), тогда как btree_gist заметно ухудшил свои показатели, проиграв уже в пять раз.
Как только относительно недалеко от моей деревне установили РЭБ, на несколько часов в день укладывающий связь, то бывшие пользователи WiMAX массово стали переходить на оптику по тарифам 100-150 тыс. рублей за подключение. Что интересно, но локальный WiFi не настолько заметно от этого страдает.
Я специально, хоть и под спойлером, объяснил, что без GIST гарантировать отсутствие пересечения диапазонов было бы проблематично. Возможно, для каких-то задач и допустимо ограничивать конкурентный доступ к БД блокировками, рискуя получить deadlock, но уж точно не для всех.
Только в достаточно специфичных случаях. И как это избежать я указал.
Тоже самое можно сказать не только про расширения, но и про сам PostgreSQL. В последнем обновлении от 13 ноября 2025 года в PostgreSQL 14-18 было исправлено почти по полсотни ошибки для каждой версии. А судя по принятым исправлениям ошибок в последующих commintfest, в следующем обновлении их будет столько же.
Следует понимать, что механизм вызова пользовательских функций, написанных на C, официально не менялся, примерно, с PostgreSQL 9.4. А обращений к БД pg_variables не требует.
Если Вы считаете, что произведенное мной тестирование недостаточно для Вашего планирования рисков, то проведите собственное.
Свой глобальный аллокатор нужен очень редко. До тех пор, пока нет возможности передать ему хотя бы пул, из которого хочется выделить память. На МК это было бы очень востребовано.
Можете оставаться при своей точке зрения. Это исключительно Ваши проблемы. В моей же сфере деятельности категорически недопустимо накладывать какие-то ограничения, непосредственно влияющие на результат выборки данных, если эти ограничения не были предварительно согласованы с заказчиком и документально зафиксированы.
Вот именно. Вы самостоятельно ввели ограничение на 15 дней нахождения основного средства на площадке, не удосужившись уточнить или согласовать это условие, хотя оно напрямую влияет на результат выборки.
Я сократил модель, так как построение btree_gist индекса на реальных объемах данных может занять часы. Но при увеличении объемов данных GIST будет ещё больше проигрывать, в чём можете убедиться.
Я бы расстался с разработчиком, который, как Вы, стал настаивать на том, что он вправе в задаче использовать какие-то ограничения, которых нет в постановке задачи.
Предлагаю на это закончить.
P.S. Немного о математике и семантике. "Сотни тысяч" - это может быть и 300 тысяч. "Около миллиона" - это может быть и 900 тыс. Дальше посчитаете?
Срок службы полувагонов в России составляет 20-30 лет. При этом следует учитывать, что в собственности у крупного оператора находится несколько десятков тысяч вагонов. Остальные вагоны под управлением - это вагоны сторонних операторов в краткосрочной аренде или по доверенности. Просто по той причине, что на станции погрузки может не быть собственных вагонов, а гнать туда порожняк может оказаться невыгодным. Отсюда и возникает большая текучка вагонов под управлением в конкретный момент времени.
Еще раз, недопустимо опираться на особенности тестовых данных, которые не заявлены в постановке задачи. Это безответственно и опасно.
В данном случае, никто не давал гарантий, что нет основных средств, которые годами находятся на одной и той же площадке. Так же как никто не давал гарантий, что основных средств будет всегда 1000, а не миллион.
Потому что таковы бизнес требования.
Если интересно, то пример был взят максимальным упрощением реальной задачи. Основные средства - это вагоны, которых в конкретный момент под управлением может быть сотни тысяч. Суммарно же было под управлением за последние 20 лет - около миллиона. Под Дебальцево несколько составов стоят уже с 2014 года. А некоторые станции находятся настолько близко, что дискретизация границ периодов используется до минут, а не дней.
Этого не было в постановке задачи, поэтому опираться на это только на основании предельно упрощённого примера недопустимо.
Ну и к теме статьи Ваш комментарий имеет весьма косвенное отношение, так как GIST он вообще не затрагивает.
Во-первых, другого источника для этого расширения я не знаю. Во-вторых, с чего Вы взяли, что не работает? В статье я лишь указал, что следует сделать, чтобы избежать рисков, возникающих, если типы строковых констант явно не указываются.
В случае кольцевого буфера DMA UB неизбежен. Компилятор никак не может определить ни то, насколько этот буфер был DMA заполнен, ни то, были ли утеряны данные в этом буфере из-за перезаписывания.
Можно только своим кодом обрабатывать эти ситуации. В первом случае отслеживая значение следующего адреса регистра канала, а во втором, восстанавливая пропуски или перезапрашивая данные протоколом более высокого уровня.
Всё о том же.
Если речь вообще о extern "C", то там тем более нет никакой возможности сообщить вызываемой программе инициализирован буфер или нет.
Я уже делал это выше
Это union. И что в нём известно компилятору, но не известно вызываемой so/dll.
Но при необходимости динамического связывания Rust ABI других вариантов не оставляет.
А если не упрощать задачу, как сделал я в статье, а выполнять реальные бизнес требования, когда вместо дат - время с дискретностью до минуты, а этих основных средств - около 100 тысяч, если учитывать так же управляемые по доверенности?
Для примера, история дислокаций у нас занимает около двух терабайт. Не слишком ли неэффективно обновлять её каждые сутки? Особенно с учётом того, что оперативный доступ к ней требуется в режиме 24/7.
К тому же, каждая запись у нас не ограничена основным средством, площадкой и периодом, как в описанном очень упрощённом примере. А имеет еще более 70 аналитик, по которым требуется фильтрация или агрегация.
Проблему изменений требований для аналитики у нас замечательно решает CH. Но он не пригоден для оперативных отчетов, которым нужны актуальные и консистентные данные из оперативной ACID БД.
Зависимость времени выборки от размеров близка к линейной для BTree, но совсем не линейна для GIST.
Например, увеличим количество основных средств в 100 раз и сформируем таблицу не из 1.3 миллиона, а из 127 миллионов записей. Теперь так же выберем записи для каждого третьего основного средства на 1 января 2020 года, получив вместо 333 уже 33333 записей в выборке.
С использованием btree_gist:
И с использованием только BTree:
Как видно, при увеличении объемов данных в 100 раз, BTree действительно показал почти линейный прирост (296 мс против 3 мс), тогда как btree_gist заметно ухудшил свои показатели, проиграв уже в пять раз.
Как только относительно недалеко от моей деревне установили РЭБ, на несколько часов в день укладывающий связь, то бывшие пользователи WiMAX массово стали переходить на оптику по тарифам 100-150 тыс. рублей за подключение. Что интересно, но локальный WiFi не настолько заметно от этого страдает.
Зависит от реализации. Например, так unsafe локализуется в вызывающем коде:
И в случае динамического связывания сложно придумать иной вариант.
Я специально, хоть и под спойлером, объяснил, что без GIST гарантировать отсутствие пересечения диапазонов было бы проблематично. Возможно, для каких-то задач и допустимо ограничивать конкурентный доступ к БД блокировками, рискуя получить deadlock, но уж точно не для всех.