Комментарии 14
может 2005 SQL а не 2003 ?
1. "При запуске ранимой " опечатка
2. вопрос: насколько шаг 7 медленнее шага 8?
2. вопрос: насколько шаг 7 медленнее шага 8?
Смотрите. допустим, таблица содержит 1000000 строк, при этом в одну страницу попадает 100 строк, тогда table scan прочитает 10000 страниц. А при использовании bookmark lookup количество логических чтений составит 100000, т.к. каждая операция bookmark lookup читает за одну операцию 1 страницу данных, а число операций будет равно числу строк.
разумеется есть еще и кэширование, благодаря чему разнится в производительности будет не так заметна на глаз, но при оптимизации запросов показатель кэширования имее не очен большой вес, в основном учитываются именнно логические чтения (сколько бы страниц читалось при отсутствии кэша)
разумеется есть еще и кэширование, благодаря чему разнится в производительности будет не так заметна на глаз, но при оптимизации запросов показатель кэширования имее не очен большой вес, в основном учитываются именнно логические чтения (сколько бы страниц читалось при отсутствии кэша)
эээ, а модификаторов у создаваемой процедуры нет? в PostgreSQL есть возмоность указать насколько динамичны используемые данные.
А на что это влияет в PosgreSQL?
Модификаторов нет. в следующей статье описан способ борьбы с этой ситуацией: http://razbezhkin.habrahabr.ru/blog/2430…
Спасибо за статью. Еще бы график какой-нибудь в конце =)
И всё-таки, основная причина использования хранимок, по моему опыту, не повышение производительности, а создание дополнительного слоя абстракции над таблицами базы данных.
И всё-таки, основная причина использования хранимок, по моему опыту, не повышение производительности, а создание дополнительного слоя абстракции над таблицами базы данных.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Производительность хранимых процедур MS SQL Server 2000/2005