У
Я не оч вкуриваю насчёт обычного индекса. Вроде, индекс используется лишь при like 'some_text%', но не при like '%some_text%'
Ну у тебя будет сканится не вся таблица, а одно поле
Size: a a a
2020 October 12
ДЛ
Если из таблицы читается только одно поле, то достаточно читать индекс, Oracle не полезет в саму таблицу
Нужен тест-кейс...
У
Нужен тест-кейс...
Ну залепи на терабайтную таблицу на текстовый столбец индекс и посмотри план
A
Ты не в тему, если что. Хотя понимаю, что тебе лишь бы чего ляпнуть.
Очень в тему. Просто ты не понимаешь что иногда нужно использовать молоток что бы забивать гвозди. А не пытаться епашить микроскопом все подряд
DC
У индекса отдельный сегмент данных на диске, вот он и будет читаться через мультиблочное чтение (fast full scan), которое гораздо шустрее обычного одноблочного
DC
У индекса отдельный сегмент данных на диске, вот он и будет читаться через мультиблочное чтение (fast full scan), которое гораздо шустрее обычного одноблочного
Если объём RAM позволяет, можно ещё настроить KEEP pool и индексу указать при создании storage (buffer_pool keep), чтобы он после первого чтения висел в памяти
DC
Нужен тест-кейс...
Если есть тестовая база с более-менее близким к боевой объёмом - сравни хотя бы logical reads для чтения одного поля через like '%%' без индекса и с ним
ДЛ
Сча пробую замутить тест..
DC
При условии, что запрос достаточно простой и CBO сможет заюзать index fast full scan
DC
Смотри что будет в плане выполнения + разницу в logical reads, на крайняк - trace 10046
АЛ
Может проще внешний поисковый движок приколхозить?
ДЛ
Смотрю. Там вообще шикарный код...
При этом description - это составное поле во view some_view_name:
Мне кажется, они безнадёжны...
SELECT * FROM (some_view_name) t_src WHERE (UPPER(t_src.description) LIKE UPPER('%некоторый текст%')) OR (UPPER(t_src.description) LIKE UPPER('%другой текст%'));При этом description - это составное поле во view some_view_name:
some_code || ' - ' || name AS description,
Мне кажется, они безнадёжны...
SG
Угу...
Inmemory с columnar compression?
ДЛ
Я построил индекс:
Но оптимизатор его не юзает
create index i_test_01 on some_base_table (UPPER(some_code || ' - ' || name)) online compute statistics;
Но оптимизатор его не юзает
У
Смотрю. Там вообще шикарный код...
При этом description - это составное поле во view some_view_name:
Мне кажется, они безнадёжны...
SELECT * FROM (some_view_name) t_src WHERE (UPPER(t_src.description) LIKE UPPER('%некоторый текст%')) OR (UPPER(t_src.description) LIKE UPPER('%другой текст%'));При этом description - это составное поле во view some_view_name:
some_code || ' - ' || name AS description,
Мне кажется, они безнадёжны...
Ну тогда функциональный индекс надо на аппер
ДЛ
Ну тогда функциональный индекс надо на аппер
Выше 👆🏻
N
Смотрю. Там вообще шикарный код...
При этом description - это составное поле во view some_view_name:
Мне кажется, они безнадёжны...
SELECT * FROM (some_view_name) t_src WHERE (UPPER(t_src.description) LIKE UPPER('%некоторый текст%')) OR (UPPER(t_src.description) LIKE UPPER('%другой текст%'));При этом description - это составное поле во view some_view_name:
some_code || ' - ' || name AS description,
Мне кажется, они безнадёжны...
может их уволить?
У
Выше 👆🏻
А блин. Дескрипшен в запросе лепится?
ДЛ
может их уволить?
Кабы я мог... 🤷♂️