|
su.dbms
- SU.DBMS ----------------------------------------------------------------------
From : Tolik Tentser 2:5020/400 31 Dec 2002 14:37:47
To : Andrew Lesnichenko
Subject : Re: Синхронизация дос тупа к БД
--------------------------------------------------------------------------------
Hi, Andrew Lesnichenko!
В чреве акулы, пойманной Mon, 30 Dec 2002 16:55:07 +0000 (UTC),
дети капитана Гранта нашли письмо на тему 'Re: Синхронизация дос тупа
к БД':
>> Почему-то забываем при этом вопросы нескольких версий записей в
>> индексах, нескольких версий статистики и секса, которого приходится
>> иметь оптимизатору запросов.
>
>А поподробнее про секс оптимизатора можно ? И хотелось бы указания
>конкретного сервера ... Hу и источника знаний, конечно ...
Поподробнее - запросто
При наличии нескольктх версий таблицы (для простоты одной) - наверно в
природе должно существовать несколько версий индексов (и селективность
одного и того же поля в каждом из них может оказаться разной), а также
несколько статистик распределения записей. Рискну предположить, что
при этом в каждой сессии, в зависимости от имеющегося в ней снапшота
оптимизатору придется по разному оптимизировать одни и те же запросы.
Позволю себе также высказать гипотезу, что это оптимизатора не
упростит и времени разработчикам БД на его улучшение не добавит. Скажу
даже, что поиск записи по индексу, в котором разные элементы имеют
разные версии - сам по себе медленнее, поскольку, кроме просто прохода
по тому-же B-дереву требует дополнительных оценок - а та ли это версия
листа.
Я уже как-то писал сюда, что в будующем, видимо, все серверы придут к
версионности, но на настоящем этапе развития науки и технике - эта
технология имеет немало нерешенных проблем и пока вряд ли может
рассматриваться как наиболее совершенная. Причем, упомянутое будущее
может оказаться весьма отдаленным. Скорее всего это произойдет не
ранее, чем у серверов БД появится запас в производительности, не
востребованной пользователями. Тогда её можно будет направить на
облегчение жизни программистов. Пока же - какртина, увы, иная -
производительность сервера БД - есть критичный ресурс и всё, что
требует его дополнительно загрузки при том же потоке транзакций - не
есть хорошо.
Bye ...
Тенцер А.Л.
tolik@katren.nsk.ru
ICQ 15925834
--- ifmail v.2.15dev5
* Origin: AO Katren (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
