|
|
|
not is distinct from & index
|
|||
|---|---|---|---|
|
#18+
Возможно ли использовать селективный индекс, имея два условия "not is distinct from "? Условия задачи: in_StorePlaceID is not null coalesce(in_PhysicalArticleID,in_ContainerID) is not null (in_PhysicalArticleID is null or in_ContainerID is null) = true Запрос: Код: plsql 1. 2. 3. 4. 5. План: Код: plsql 1. 2. 3. 4. 5. 6. 7. Селективность по StorePlaceID низкая, но индексы по PhysicalArticleID, ContainerID разного рода никогда не используются. Поскольку это фрагмент функции pl/pgsql, несложно проверить, какой из двух in_PhysicalArticleID, in_ContainerID not null, и применить явный запрос. В этом случае используется селективный индекс по StorePlaceID, PhysicalArticleID, ContainerID. План идеальный. Технически проблема решена. Но есть ли способ получить оптимальный план, используя исходную конструкцию из двух not is distinct from? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.12.2014, 14:06 |
|
||
|
not is distinct from & index
|
|||
|---|---|---|---|
|
#18+
tadmin, индексами в postgres покрываются только запросы вида поле operand значение IS NOT DISTINCT не является операндом и ни при каких условиях индексами покрываться (на текущих версиях) не будет PS: да это возможно сделать запатчив парсер/планировщик но на данный момент не сделано (я даже более менее понимаю как бы я делал - а именно ввел бы для всех типов специальный operand скажем ~=~ по смыслу эквивалетный IS NOT DISTINCT и подменял бы на этапе парсинга). --Maxim Boguk www.postgresql-consulting.ru ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.12.2014, 14:42 |
|
||
|
not is distinct from & index
|
|||
|---|---|---|---|
|
#18+
Maxim Boguktadmin, индексами в postgres покрываются только запросы вида поле operand значение IS NOT DISTINCT не является операндом и ни при каких условиях индексами покрываться (на текущих версиях) не будет PS: да это возможно сделать запатчив парсер/планировщик но на данный момент не сделано (я даже более менее понимаю как бы я делал - а именно ввел бы для всех типов специальный operand скажем ~=~ по смыслу эквивалетный IS NOT DISTINCT и подменял бы на этапе парсинга). --Maxim Boguk www.postgresql-consulting.ru что крайне неудобно и непоследовательно ,когда есть индекс по списку (f1,....fn) и надо найти по точному совпадению ROW (т.е собственно по (f1,....fn) IS NOT DISTINCT FROM (v1,....vn)) ,а надо ручками раскладывать все пары в гробики Код: sql 1. 2. 3. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.12.2014, 15:02 |
|
||
|
not is distinct from & index
|
|||
|---|---|---|---|
|
#18+
Maxim BogukIS NOT DISTINCT не является операндом и ни при каких условиях индексами покрываться (на текущих версиях) не будет Вот оно что... Верно понимаю, что это единственный экземпляр скалярного "не оператора"? Замена на if & явное "=" дало неплохое ускорение. Конструкция is distinct всегда казалась мне подозрительно изящной -) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.12.2014, 15:14 |
|
||
|
not is distinct from & index
|
|||
|---|---|---|---|
|
#18+
tadmin, Кстати это есть в доке "(At present, IS NOT DISTINCT FROM is handled much less efficiently than =, so don't do this unless you must. See Section 9.2 for more information on nulls and IS DISTINCT.)" но почему то в pl/pgsql части ( http://www.postgresql.org/docs/9.3/static/plpgsql-statements.html) про скалярный не оператор в каком то смысле под это попадает field IS NOT NULL (который никогда не пойдет по индексу даже если NULL's составляют 99.9% значений) насколько я помню. При этом field IS NULL индексом покрывается. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.12.2014, 16:42 |
|
||
|
|

start [/forum/search_topic.php?author=oravm&author_mode=last_posts&do_search=1]: |
0ms |
get settings: |
8ms |
get forum list: |
10ms |
get settings: |
7ms |
get forum list: |
17ms |
get settings: |
9ms |
get forum list: |
17ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
69ms |
get topic data: |
12ms |
get forum data: |
4ms |
get page messages: |
55ms |
get tp. blocked users: |
2ms |
| others: | 803ms |
| total: | 1019ms |

| 0 / 0 |
