Существует табличка с 300000 записей на Cache' и на MS SQL Server. Все поля и индексы аналогичные. Выбор количетва строк в Каше занимает около 3 сек, а на SQL Server 0.05 с. Как можно убыстрить. И вообще может есть статьи по TuneTable и оптимизации запросов?

=Dimon=Существует табличка с 300000 записей на Cache' и на MS SQL Server. Все поля и индексы аналогичные. Выбор количетва строк в Каше занимает около 3 сек, а на SQL Server 0.05 с. Как можно убыстрить. И вообще может есть статьи по TuneTable и оптимизации запросов?
Обманул :)
Не идентичные. В Cache' связана Ralationship с parent. То есть все данные хранятся в parent. И получается, что для каждого парента sql запрос считает количество children.

Класс 1
Class TEST.Data Extends (%Persistent, %Populate) [ ClassType = persistent ]
{

Property name As %String(MAXLEN = 2000);

Property fullname As %String(MAXLEN = 2000);

Property producer As %String(MAXLEN = 255);

Property productCode As %String(MAXLEN = 255);

Property type As %String(MAXLEN = 2000);

Property isConnected As %Boolean;

Property deleteFlag As %Boolean;

Property countryID As %Integer;

Relationship testItem As TEST.ParentData [ Cardinality = parent, Inverse = itemList ];

}
Класс 2
Class TEST.ParentData Extends (%Persistent, %Populate) [ ClassType = persistent ]
{

Property name As %String(MAXLEN = 2000);

Relationship itemList As TEST.Data [ Cardinality = children, Inverse = testItem ];

Property rowCount As %Integer;

Property decodeRowCount As %Integer;

}

Запрос SELECT count(*) FROM TEST.Data

Вадим, когда используем Relationship нельзя использовать bitmap индекс. По крайней мере в Cache 5.2 этого сделать не получилось, ругается.

Так что делать то? Пытался разнести хранение у чилдренов, не помогает. Если самому написать программу и пробегать по глобали с индексами все ок, можно быстрее получать, но опять же надо тогда и ResutSet переписывать, чтоб он Count считал по-моему. И придется для каждого relationship "parent - children" адаптировать программу.

Alexey MaslovА зачем Вы используете "parent-child"? Я тоже когда-то был на распутье: казалось, что такое хранение может ускорить обработку иерархических запросов. Но тестирование показало, что это не так, и при хранении тех же данных в отдельных таблицах (если угодно, связанных по "one-many"), все шевелилось заметно быстрее. Возможно, этот эффект не носит вселенского характера, но попробуйте.
К тому же, перейдя к "one-many", вы сможете использовать bitmap индексы, а это тоже плюс.
Используем за тем, что при parent-to-children children не может существовать без парента, в отличие от one-to-many. При удалении родителей автоматически удаляются дети. Другое дело, что почему-то выборка не ускоряется, если я начинаю хранить детей в отдельной глобали. Все равно при запросе начинает делать full scan родителей и перебор его детей. Да и индексы опять же существуют по детям. Возможно, что здесь дело совсем не в отношении, а как раз таки в производительности на конкретной платформе. Я пробовал на прямом доступе перебор по индексу, времени ушло столько же.

Александр Коблов Ерунду написал.
Попробуйте добавить к TEST.Data индекс Index NewIndex1 [ Extent ];
Не помогло.
В общем переделал все. Сделал отношение one-to-many. Создал битмап-индекс. Запрос подсчета количества для 1,5 млн строк выполняется 1 милли!!! секунду, да и что там считать :) количество строк уже хранится в узле глобала.

krvsaТ.е. если хочеш чтобы запрос


выполнялся быстро - нужно иметь хотябы один битмап-индекс?
----------
Cache for Windows (x86-32) 2007.1.3 (Build 607) Wed Oct 17 2007 02:12:09 EDT

Не только. Еще нужно отказаться от parent-children.

krvsa=Dimon=Еще нужно отказаться от parent-children.
Мы его и не используем. ]
А вообще таблиц "миллионок" много с relationship? Какая производительность и конфигурация серверов?