Для ванилы мы не поддерживаем, только для энтерпрайза. Хотя для ванилы (кроме мастера) могут быть только пока нестабильные тесты быть), в остальном работает)

simplepersonru 11 дек 2025 в 11:30

Ограничения для IN (VALUES …) → = ANY(array)
...
Трансформация не применяется, если внутри VALUES: ...[и далее по пунктам]

Представим такой код:

SELECT ten FROM onek t WHERE unique1 IN (VALUES (0), (1), (NULL), (2));

Есть ли смысл в частичном преобразовании в ANY? т.е. примерно вот так: (все что можно, суем в ANY, остальное оставляем как было)

SELECT ten FROM onek t WHERE 
unique1 = ANY('{0, 1, 2}'::numeric[])
OR unique1 IN (VALUES (NULL));

p.s. я не силен в особенностях внутреннего устройства postgresql

windsurfer69 26 дек 2025 в 03:58

Имейте в виду, что если вы написали unique1 IN (0,1), то это просто эквивалент unique1=0 OR unique1=1 - обычное выражение. А если добавили VALUES, то у вас скобки возвращают подзапрос со всей вытекающей обработкой подзапроса. И в документации IN описан в двух местах, как два оператора. VALUES - это эквиваент SELECT 0 union SELECT 1 - фактически обрезанная форма команды SELECT без FROM.

Alena0704 1 янв в 15:15

Семантически такое переписывание корректно, но практической пользы в нём нет.
NULL в ANY с строгим оператором всё равно не участвует в сравнении, поэтому вынос только не-NULL констант в ANY при сохранении IN (VALUES (NULL)) ничего не меняет.
Без кода это действительно сложно пояснить, но если смотреть на реализацию: btpreprocess_array_keys (используется при обработке индексных условий) игнорирует NULL и работает только с константными значениями. В случае BitmapIndexScan результат дополнительно перепроверяется через ExecQualAndReset, который обращается к данным, хранимым в таблице.) ExecEvalScalarArrayOp также корректно обрабатывает массивы и формирует результат в зависимости от строгости оператора.
Кстати, когда коммитили в 18-ю, добавляли сразу туда NULL элементы и план выглядит так:

postgres=# create table t (x int);
CREATE TABLE
postgres=# explain analyze SELECT x FROM t WHERE x IN (VALUES (0), (1), (NULL), (2));
                                           QUERY PLAN                                           
------------------------------------------------------------------------------------------------
 Seq Scan on t  (cost=0.00..48.25 rows=38 width=4) (actual time=0.020..0.021 rows=0.00 loops=1)
   Filter: (x = ANY ('{0,1,NULL,2}'::integer[]))
 Planning:
   Buffers: shared hit=71
 Planning Time: 3.584 ms
 Execution Time: 0.157 ms
(6 rows)

Sleuthhound 11 дек 2025 в 14:52

На фоне приседаний многих компаний выпускающих энтерпрайзные postgres для 1С у меня возник вопрос:

Это феномен чисто Российский когда компания производитель СУБД оптимизирует СУБД под конкретный софт (под 1С) или это имеет место быть и в других кровавых Ынтерпрайзах типа MSSQL/Oracle ?

Если ли другие производители СУБД (MSSQL/Oracle) подстраивают свой разработки под конкретный софт, то можно еще примеры под какой софт они подстраиваются?

windsurfer69 26 дек 2025 в 04:11

И Oracle, и Microsoft бились за SAP (против DB2), внося изменения в свои базы под лозунгом - лучшая БД для SAP. Именно так прогрес идет у баз данных. Улучшение для 1С не означает, что у остальных начнутся проблемы. 1С генерирует запросы, и там есть определенные закономерности (в том числе - частое использование IN и далее список из тысячи значений - так программист 1С привык писать код), и эти закономерности можно оптимизировать. Почему нет? FreeBSD 10 лет назад оптимизировалось под Postgres, чтобы ускорить свою систему работы с памятью и файловой системой

alex7six 4 мар в 10:36

Вторая и третья оптимизации для 1С не актуальны, т.к. там таких кейсов почти нет)

Зарегистрируйтесь на Хабре, чтобы оставить комментарий