Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Помогите с запросом
|
|||
|---|---|---|---|
|
#18+
ASCRUSВот при JOIN/EXISTS/IN как раз выборка и посадится на INDEX SCAN, а WHERE CASE уйдет на TABLE SCAN и использовать индексы оптимизатор не будет. Это кстати насколько я понимаю, не только к ASA относится, но и любому РСУБД - хотел бы я увидеть сервер, который Ваш последний запрос на индексы подсадит для фильтрации по нужным условиям.Никто не мешает развернуть CASE в обычное (AND ... OR) условие, котооре также легко посадится на индекс. А в остальном - согласен... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.04.2006, 10:21 |
|
||
|
Помогите с запросом
|
|||
|---|---|---|---|
|
#18+
Владимор КоневНикто не мешает развернуть CASE в обычное (AND ... OR) условие, котооре также легко посадится на индекс. В том то и дело, что не развернете. Это все равно что делать условие на результат функции, типа такого: WHERE trim(data)='конкретная строка', тут индекс по data не поможет. Ваш запрос, применительно к ситуации: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. ( WorkTable ( Filter [ expr( 1, 0, t2.spell_word_id, t2.flag_locate ) = 2 : 5% Guess ] ( Window ( IndexScan ( tovar_spell_words t2 ) tovar_fk ) ) ) ) ) Анализируем план: Первая ступень, скаинрование индекса по tovar_id, только не на конкретное значение, а ВСЕГО, из него делает окна по общим значениям, применяет условия поиска, фильтрует лишнее, и все это делалось во временной таблице, которая в основном будет лежать в "файле подкачки" asa_temp. Явно быстродействием такой подход не блещет, потому что напрямую зависит от объема индекса, таблицы (зависимость вроде квардратичная получается). Как видно подходов масса, результат выборок один, а планы принципиально разные. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.04.2006, 11:37 |
|
||
|
Помогите с запросом
|
|||
|---|---|---|---|
|
#18+
Да, и еще, OLAP функции нужны для статистической обработки как можно большего массива данных, и чем больше, тем больше выигрыш от их применения. А делать анализ всей таблицы для поиска нескольких значений - это абсолютно неправильно, для этого есть индексы и правильная организация хранения данных. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.04.2006, 11:40 |
|
||
|
Помогите с запросом
|
|||
|---|---|---|---|
|
#18+
iLLer Владимор КоневНикто не мешает развернуть CASE в обычное (AND ... OR) условие, котооре также легко посадится на индекс. В том то и дело, что не развернете.Если честно, то я в упор не увидел в анализируемом тобой варианте каких-то бы ни было условий фильтрации во внутреннем подзапросе... Я же предлагал делать примерно так: 1) Выбрать по условию часть записей из таблицы, удовлетворяющих тому, что написано в CASE, только при этом развернуть CASE в обычные AND/OR - условия (что бы индексы можно было заюзать) 2) Наложить на полученный результат аналитическую функцию 3) Обернуть полученное и отфильтровать по условию, удовлетворяющему поставленной задаче. Ну где-то вот так: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.04.2006, 11:47 |
|
||
|
Помогите с запросом
|
|||
|---|---|---|---|
|
#18+
Тогда уж правильнее: Код: plaintext -- www.rusug.ru - портал русскоязычной группы пользователей Sybase ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.04.2006, 12:04 |
|
||
|
Помогите с запросом
|
|||
|---|---|---|---|
|
#18+
Ничего принципиального не изменилось: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. ( Plan [ Total Cost Estimate: 18.08577018 ] ( WorkTable ( Filter [ expr( 1, 0, t2.spell_word_id, t2.flag_locate ) = 2 : 5% Guess ] ( Window ( IndexScan ( tovar_spell_words t2 ) tovar_fk[ ( t2.spell_word_id IN ( 430084, 430881 ) : 4.692411795% Statistics ) AND ( t2.flag_locate = 1 : 100% Statistics ) ] ) ) ) ) ) Согласен с ASCRUS. Операция OR вносит свою лепту, либо отказываемся от индекса по значениям, либо свойствам. Вообщем, думаю что уже ясно, что OLAP не сюда. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.04.2006, 12:11 |
|
||
|
Помогите с запросом
|
|||
|---|---|---|---|
|
#18+
2 iLLer, ASCRUS. ОК, уболтали... Я сам с ASA просто никогда не работал, так что верю вам на слово :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.04.2006, 12:35 |
|
||
|
Помогите с запросом
|
|||
|---|---|---|---|
|
#18+
Не думаю, что в Оракле ситуация будет чем то другая - во всяком случае на моей памяти для 9-ой версии поведение оптимизатора будет похожим :) -- www.rusug.ru - портал русскоязычной группы пользователей Sybase ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.04.2006, 13:11 |
|
||
|
|

start [/forum/topic.php?fid=55&msg=33685711&tid=2012893]: |
0ms |
get settings: |
5ms |
get forum list: |
8ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
47ms |
get topic data: |
6ms |
get forum data: |
2ms |
get page messages: |
29ms |
get tp. blocked users: |
1ms |
| others: | 206ms |
| total: | 308ms |

| 0 / 0 |
