|
su.dbms
- SU.DBMS ----------------------------------------------------------------------
From : Sergey Prach 2:5020/400 05 Jan 2003 01:29:32
To : Andrey Zhukov
Subject : Re: Синхронизация доступа к БД
--------------------------------------------------------------------------------
Hi!
"Andrey Zhukov" <Andrey.Zhukov@p15.f54.n5025.z2.fidonet.org>
сообщил/сообщила в новостях следующее:
news:1041632743@p15.f54.n5025.z2.ftn...
> >> Самый яркий пример - select count(*) from table -
> >> у IB происходит полный перебор всех записей и всех их версий - и на
> SP> А это ну уж очень похоже на горькую правду, с сухим остатком. Вот
> SP> только смысл в индексах резко теряется, если они содержат мусор.
> Ситуация, когда в одной транзакции идет чтение из таблицы, а в другой в
это же
> самое время выполняется какой-то огромный insert или update, IMHO все-таки
не
> вполне обычная - это скорее похоже на какую-то разовую массовую заливку
данных,
> а не на нормальную работу системы. А если вторая транзакция изменяет
только
> небольшое количество записей (по сравнению с их общим числом), то и мусора
в
> индексах не много и на общую картину он сильного влияния не оказывает. В
общем,
> все не так страшно, хотя при работе с IB эту его особенность надо
учитывать...
Я тебе про жаренное, а ты мне про стриженное. Я про то, что раз индексы
хранят все версии, то падает эффективность использования индексов, особенно
уникаьных. Так как приходится индекс строить всегда по большему набору
атрибутов (базовый набор атрибут + N-версии). Т.е. даже для такого часто
используемого
индекса, как по целочисленному 32-х битовому целому, реальный размер записи
в индексе значительно больше, а значит необходимо больше пространства под
индекс, увелечение процессорных операций, и другие "приятности".
--
С уважением,
Сергей Прач
=================
Please, send you private mail to: s_pratch@mail.ru
--- ifmail v.2.15dev5
* Origin: LtawaSoft (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
