С приближающимся завершением отпускного сезона Вас, дорогие коллеги.

У меня неприятность. Примерно вот такая:

Есть иерархия наследования, состоящая из 3-х хранимых классов. Наверху - очень много объектов, внизу - почти нету (так получилось в конкретном случае)


для первой тысячи записей:

select * from test.A
Быстродействие: 0.036 Секунд 5009 глобальных ссылок
План запроса
Относительная стоимость = 947000
Read master map test.A.IDKEY, looping on ID.
For each row:
Output the row.

select * from test.B
Быстродействие: 0.154 Секунд 408012 глобальных ссылок
План запроса
Относительная стоимость = 587000
Read master map test.B.IDKEY, looping on ID.
For each row:
Output the row.

select * from test.C
Быстродействие: 0.168 Секунд 448008 глобальных ссылок

План запроса
Относительная стоимость = 551000
Read master map test.C.IDKEY, looping on ID.
For each row:
Output the row.

Читать так: С УМЕНЬШЕНИЕ КОЛИЧЕСТВА ДАННЫХ В ТАБЛИЦЕ ВРЕМЯ ВЫБОРКИ ИЗ НЕЕ РАСТЕТ (а как вы хотели!?)

ORDER BY серьезно меняет картину, ибо движок SQL наконец становится похожим на результат работы нормального программиста, а не козла какого-то плохого программиста...
Он вдруг понимает таки, что можно было пройтись по короткому индексу:
Быстродействие: 0.046 Секунд 14008 глобальных ссылок

Ну да и х... с ним... (я хотел сказать "хрен", но передумал) То, что в Каше проблему гланд должен решать проктолог, всем давно известно, и все давно привыкли (соответствующие резиновые перчаточки, уверен, есть у всех...)

Теперь, собственно о неприятностях:

1. Явное указание
Parameter EXTENTSIZE As INTEGER = 100;
Не решает проблему (хотя для чего оно тогда нужно!?)

2. Непонятно, как исключить проход по IDKEY в случае, когда для движка IDKEY - не последний в ряду возможных индексов, тоже непонятно... Т.е. SQL сразу кидается на IDKEY и я не могу ему сказать
%IGNOREINDICES "IDKEY" или %IGNOREINDICES "test.A.IDKEY", чтобы он "узрел", наконец, #@$@*, что есть довольно удобный, а главное, быстрый индекс???

3. Непонятно, как гарантировать, что при действиях пользователя с таблицей (например, изменение поля, по которому идет сортировка), не приведет к уходу индекса в IDKEY - где мильены записей...

И вообще, что это за "test.B.IDKEY" такой. Судя по структуре глобалов, сразу достучаться в данные класса test.B невозможно.
И "test.B.IDKEY" равнозначно "test.А.IDKEY при условии, что первый элемент в списке данных ~test.B~"

Вот так примерно и начинаются рабочие будни... блин...

Скажу проще:

Если мне нужно сделать выборку по классу, находящемуся в иерархии наследования, последнее, что я стал бы использовать, это IDKEY. Если в моем, конкретном классе определен хотя-бы один, пусть самый завалящий, но в нужном классе, индекс, проход по этому индексу даст тыщапицотразовый выигрыш в производительности без ущерба логике.

Но в мегасуперобъектнопостреляционной Cache за последние 10 лет (и даже больше кажись объекты у них) до этого не додумались...

Все, складываю манатки и сваливаю...
Шутка.

newbie',

Спасибо, буду посмотреть... А я мимо "пулял" оказывается... Вашу ссылку читал, но пытался использовать вот так:

Index PIndex2 On P [ Extent ];

На что компилер ругался...

newbie',

Все равно чаще пытается идти по "длинному" индексу. Если в условии использовано индексированное свойство.

И ищет полторы секунды ;( (нолик должен быть)

Если отсекать индексы этого свойства (унаследованные в т.ч.), то заканчивается все равно на IDKEY, а до созданного с Вашей помощью индекса оптимизатор вообще не доходит.

Как-то так... Получается, пользы от такого индекса почти и нету - только для выборки всех данных класса...

Блок А.Н.d $system.SQL.TuneTable("test.*",1,1)
делали?

Я против того, чтобы делать то, что непонятно как работает... Да еще и зависит от текущего количества записей в базе. Сразу после завершения проектирования эта команда сильно мешает жить... Как показал мой опыт, применять ее можно только после "набивки" базы данными. И то в случае экстренной необходимости выправить производительность.

Ручками с экстентсайзом и селективностями игрался. Результат либо никакой, либо отрицательный. В этом конкретном случае, конечно.

Блок А.Н.,

Спасибо, ход мыслей примерно понятен... Но остаюсь при своем мнении - ИС должны были об этом позаботиться лет 5-ть назад.