Hello, Nikolay!
Nikolay Ponomarenko wrote:
Да, эта проблема известна, ее обсуждали еще по приведенной ссылке.
Интересен уже сам доступ к данным, есть ли разница, к примеру при
доступе по PK для 100 тысячной таблицы и для миллиардной?
:-) там же по ссылке примеры запросов приведены.
Причем, один буржуй даже некоторым образом наехал на результаты,
мол, у вас там все закэшировано в дупель и т.п.
Я даже несколько обозлился, проверил еще раз, каждый запрос
сразу после коннекта, дисконнект, и т.п.
И еще сразу после загрузки компа. Все соответствует.
Я бы мог выполнить почти любой запрос с этой базой,
какой попросишь, только сначала надо обратно этот sata-диск
подключить :-)
понятно, что пример не чистый и влиять может куча факторов. Просто
интересно, есть ли смысл продолжать что-то тестить, или действительно,
есть какие-то доп. накладаные расходы при работе(пусть просто при
чтении) со свехбольшими таблицами?
В моем случае основополагающим был ввод-вывод. я при запуске
любых запросов постоянно смотрел на диски в perfmon.
Ну и, разумеется, в большинстве реальных запросов замедление есть
пропорционально как объемам, так и степени "размазанности" таблицы
по базе при одинаковых объемах.
Например, в общей таблице (в статье), где указано время select count
и время создания индексов видно, что хоть ORDERS и меньше по объему
чем NEW_ORDER (25 гиг против 32 гига), но из-за размазанности и
утроенного кол-ва записей (111 миллионов против 372 миллионов)
ORDERS по count и созданию индексов в 1.5 раз медленнее.
Если бы таблицы были мельче, то разница в 1.5 раз была бы менее
заметна. А так - 20 минут и 30 минут, это же 10 минут разницы.
--
Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34
