|
поиск по многоколоночному индексу нескольких комбинаций
|
|||
---|---|---|---|
#18+
Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25.
Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46.
Жаль, что в последних двух запросах постгрес не использует условие при поиске по индексу в Index Cond. При том, что с третьим запросом справляется прекрасно! Как можно ускорить последние два запроса, чтобы условие проверялось в Index Cond? Придумал только вариант переформулировать на union all. PS: В этом тесте положение исправляет включенный bitmapscan. В таком случае постгрес использует BitmapOr. Но в моем реальном запросе замена IndexScan на BitmapIndexScan приводит к выбору худшего плана на последующих этапах. ... |
|||
:
Нравится:
Не нравится:
|
|||
05.05.2017, 16:49 |
|
поиск по многоколоночному индексу нескольких комбинаций
|
|||
---|---|---|---|
#18+
LeXa NalBat, или расписать поэлементный AND или сделать индекс по row() (создать тип) , или попользоваться тем, что пж сам умеет разбирать поэлементно в таком синтаксе : Код: sql 1.
Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14.
... |
|||
:
Нравится:
Не нравится:
|
|||
05.05.2017, 17:29 |
|
поиск по многоколоночному индексу нескольких комбинаций
|
|||
---|---|---|---|
#18+
ещё вариант Код: sql 1.
Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12.
... |
|||
:
Нравится:
Не нравится:
|
|||
05.05.2017, 17:37 |
|
поиск по многоколоночному индексу нескольких комбинаций
|
|||
---|---|---|---|
#18+
qwwqещё вариант Код: sql 1.
Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12.
*RESPECT* решение красивое и "идеологически выдержанное" почему то большая часть разработчиков про конструкцию values () не догадывается к сожалению. -- Maxim Boguk dataegret.ru ... |
|||
:
Нравится:
Не нравится:
|
|||
05.05.2017, 17:57 |
|
поиск по многоколоночному индексу нескольких комбинаций
|
|||
---|---|---|---|
#18+
Maxim Boguk, думаю ТС-а это не спасёт , т.к. примитивный вариант: Код: sql 1. 2. 3.
он не поюзал. т.е. он с какими то своими тараканами сражается а не с планировщиком ... |
|||
:
Нравится:
Не нравится:
|
|||
05.05.2017, 19:08 |
|
поиск по многоколоночному индексу нескольких комбинаций
|
|||
---|---|---|---|
#18+
кажется понял: тс хотел бы ,вероятно, уйти от какого--то BitmapAnd (долгого построения карты по 2-м индексам [могу врать]), но т.к. енейбл общий -- чисто технический enable_bitmapscan, то 2 логически разных действия (2индексный поиск[BitmapAnd] и выбор из списка BitmapOR) регулируются одним и тем же крыжиком. Т.е. крыжиков в пж мало для такого тюнинга. с другой, для листа (или перечисления ключей в OR) не предусмотрено использования планером nestedLoop-а, и при дизейбле bitmapscan планер сразу проваливается в секскан для списка. (пока строк не станет слишком много). а подсунуть ему сет вместо листа можно только переписав запрос. (тут оно и "опускается" до нетстед лупа) могу врать. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.05.2017, 22:03 |
|
поиск по многоколоночному индексу нескольких комбинаций
|
|||
---|---|---|---|
#18+
ср: Код: sql 1.
... |
|||
:
Нравится:
Не нравится:
|
|||
06.05.2017, 22:05 |
|
поиск по многоколоночному индексу нескольких комбинаций
|
|||
---|---|---|---|
#18+
qwwq, спаибо! Вариант с values очень интересный, элегантнее union all, обязательно его попробую в боевом запросе. qwwqпримитивный вариант ... UNION ALL он не поюзалУже поюзал, работает. Буду пробовать values. ... |
|||
:
Нравится:
Не нравится:
|
|||
12.05.2017, 09:25 |
|
|
start [/forum/topic.php?fid=53&fpage=74&tid=1996524]: |
0ms |
get settings: |
12ms |
get forum list: |
12ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
27ms |
get topic data: |
13ms |
get forum data: |
3ms |
get page messages: |
50ms |
get tp. blocked users: |
2ms |
others: | 334ms |
total: | 459ms |
0 / 0 |