Суть какая.
Есть запрос

select * from bla-bla where upper(x) = 'PETYA'

Насколько я понимаю, работает он очень медленно, т.к. делается фулскан таблицы.

В оракль можно сделать индекс по функции. Типа поле х, функция upper и всё полетело.

Как бороться с этим делом в субейз?
Можно, конечно, сделать дополнительное поле и тригер, который будет класть туда значение в апперкейс и повесить на него индекс... но это как-то коряво.

Кстати, сервер ASE 12.5.4.

В этой версии вычислимых полей нет, индексов LF нет (это правда к другой проблеме относится)...

На таблице в пару миллионов записей поиск по условию upper() = '' занимает около 800 ms.
Не самое шустрое создание. Или я готовлю не правильно? :)

Dim2000
Прекрасно. Если время выполнения запроса нельзя засечь по наручным часам
- он достаточно быстр :).


Угу. Только на самом деле это upper возникает в селекте включающем join четырёх таблиц и время выполнения запроса растягивается на 90 секунд :)
Если в этом запросе убрать upper - всё отрабатывет за 100ms.

Я разделил запрос на два. В одном делает выборка во временную таблицу (с upper), которая затем используется во втором запросе.

На первый уходит около секунды, на второй - доли секунд, т.к. под нужное условие попадает не очень много значений.

Т.к. запрос не очень часто дёргается, то проблемы большой нет. Но всё-таки хотелось бы найти способ достичь идеала в 100ms %)

up
P.S. Кстати проблема как я понимаю не в отсутвии такого индекса, а в отсутсвии точной статистики из-за использовании функции и соответсвенно в другом плане запроса.

Странное утверждение... Можно расширенный вариант этого утверждения?

Мне так кажется, что иного плана, кроме как table scan, в данном случае быть не может. Надо же как-то значения функции получить?
Индекс "закешировал" бы вычисленные значения функции и можно было бы забыть о table scan'e, как о страшном сне.



А что скажите о таком варианте (есть индекс по x.y):


Работает в 9 раз быстрее, чем простой where upper(x.y) = upper(@VALUE).

Можно огрести косяков на сравнении строк в разных регистрах?

MasterZiv
Это не совсем корректно, поскольку ты в запросе зашиваешь порядок сортировки
строк. Т.е. предполагаешь его вполне определенным. А он может и поменяться.
Если это не пугает, тогда все хорошо.

Имеется ввиду ASC/DESC в index'e или что-то другое?

MasterZiv
Но может все же хранить все эти строки в одном регистре, или использовать
нечувствительный порядок сортировки ?

Когда система большая выяснить почему что-то сделано так, а не по другому бывает очень сложно. Н-р, в dev базе все значение в uppercase, а в продакшине какой-то скрипт или флоу создаёт записи, где есть и нижний и верхний регистр. Найти все концы, чтобы понять можно ли не сохранять регистр, существенно сложнее, чем мириться с небольшой задержкой в редко используемой функции, которую нужна только саппорту. Даже на задержку в 90 секунд долгое время никто не жаловался :)

Ggg_old надо использовать не чувствительныей к регистру строки.
А чуток по подробнее можно? Гугль не выдал ответа как такое делается :)

Ggg_oldНу это свойство базы данных.. case senstive чего-то там...
Я с АЗЕ давно не работаю
^{все наши на www.corba.kubsu.ru}

Sybase ASE servers are case sensitive by default. This is a server-wide setting driven by the default character set and the sort order. Changing this impacts both object names and data itself so if you have to do this, expect unexpected consequences.

There is no way to change case sensitivity on a per-connection basis, or on a per-database basis. Changing it on an existing server is difficult and involves a lot more steps. But I recently had to make this change on a new install, having no databases and no data. It's much easier in that case.

Судя по выше процитированному - это не вариант. Во первых, под влияние попадает вся база, а не одна колонка. Во вторых, unexpected consequences лишают возможности заниматься такими фокусами в приложении, которое вращает большими деньгами (банковский софт). Слишком велики риски.