Так я и думал. Сделайте и сообщите результаты  

уже не получится
эксперемент закончился, а 25ГБ освобождены

Я вот создал тестовую базу с единственной таблицей из двух полей - числового (первичный ключ) и строкового (100 символов) и заполнил её миллионом записей. Получилась БД размером 120 МБ. Запрос на подсчёт записей выполняется за 1s 391ms.
Вообще в любой БД индексированные чтения и неидексированные отличаются длительностью на 3 порядка   

Это сообщение отредактировал(а) Esperito - 4.4.2008, 13:53

я удалил уже тестовую базу данных
но для эксперементов с индексом начал её восстанавливать
по какому полю вообще лучше всего вводить индекс?

создал индекс по первому попавшемуся полю, но легче то не стало

Это сообщение отредактировал(а) ilya198293 - 8.4.2008, 12:09

Попробуй создать первичный ключ по числовому полю.

Я создал индекс по полю типа double precision
но ничего не произошло по ускорению запроса
может нужно чтоб поле или группа полей были уникальны или может ещё что-то?
на show index реакция нормальная

Первичным ключом делают обычно поле типа INTEGER. Кроме того, эффективности любого индекса зависит от его селективности, т.е. если среди всех значений данного поля очень мало уникальных, эффективность будет крайне низкой.

т.е. я так понимаю, что нужно вводить дополнительное поле со счётчиком или организовывать индекс по группе полей, чтоб в этой группе была уникальность в максимально выраженной форме

В общем, чем иметь индексы с низкой селективностью, лучше их не иметь вообще.
Да, и вот ещё что. Запрос на подсчёт записей - это не критерий для сравнения с другими СУБД, ибо Firebird и Interbase имеют движки многоверсионных записей, а некоторые другие - нет, тут могут быть неоднозначности... К тому же, мусор в базе и фрагментация таблиц тоже влияет на скорость (после вставки таблиц друг в друга я бы сделал backup/restore).
Лучше сравнивать скорость сложных запросов. Да собственно, в интернете очень много статей по сравнению 
Если есть вопросы, можете задать их монстрам на форуме ibase.ru