Открыть список
Как стать автором
Обновить

Комментарии 14

может 2005 SQL а не 2003 ?
так может стоит отредактировать название? ;)
а в остальном спасибо, никогда не замечал раньше, но на уровне подсознания чувствовал что не все так гладко со сторедами. есть над чем подумать :)
поправил.
чуть позже напишу, как из таких ситуаций можно выходить.
1. "При запуске ранимой " — опечатка

2. вопрос: насколько шаг 7 медленнее шага 8?
Смотрите. допустим, таблица содержит 1000000 строк, при этом в одну страницу попадает 100 строк, тогда table scan прочитает 10000 страниц. А при использовании bookmark lookup количество логических чтений составит 100000, т.к. каждая операция bookmark lookup читает за одну операцию 1 страницу данных, а число операций будет равно числу строк.

разумеется есть еще и кэширование, благодаря чему разнится в производительности будет не так заметна на глаз, но при оптимизации запросов показатель кэширования имее не очен большой вес, в основном учитываются именнно логические чтения (сколько бы страниц читалось при отсутствии кэша)
эээ, а модификаторов у создаваемой процедуры нет? в PostgreSQL есть возмоность указать насколько динамичны используемые данные.
А на что это влияет в PosgreSQL?
На то как кешируются результаты и планы у хранимых процедур.
эээ... а прямее способа точно нету?
избегать такого широкого диапазона результирующей выборки. или перекомпилировать хранимые процедуры по какому то алгоритму, или сделать их так, чтобы откомпилированный код не сохранялся в процедурном кэше.
Спасибо за статью. Еще бы график какой-нибудь в конце =)
И всё-таки, основная причина использования хранимок, по моему опыту, не повышение производительности, а создание дополнительного слоя абстракции над таблицами базы данных.
Microsoft "говорит" что и для оптимизации производительности в своих официальных курсах.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.