 |
|
|
su.dbms.sql- SU.DBMS.SQL ------------------------------------------------------------------ From : Dmitry Kuzmenko 2:5020/400 22 Feb 2001 13:50:47 To : All Subject : Re: индексы в ИБ -------------------------------------------------------------------------------- Hello, Vladimir! Vladimir Pavlikov wrote: > > мне уже ответили - действительно overhead и затраты на "внедрение" этой > > фичи превышают выгоду от ее использования. > > Ответ не принимается :( Отсутствие номера транзакций в индексе - один из > самых больших обломов в IB. Оверхед и внедрение, как и выгода - это то, > о чем судить должен пользователь, а не производитель. Если же речь о ра- > боте производителя, то это лицемерие :( привожу два ответа: Ответ Харрисон: > I think that making "select count" faster by making everything > else slower is a mistake. (I also think a lot of other things, > but that's the relevant one.) > > First, adding the transaction id makes every node four bytes bigger, > and it must be propagated up the tree. > > Second, if you have multiple versions of a record with a single > key value, there's currently only one index entry. > > When updating, InterBase checks to see if the index entry already > exists, and if so, doesn't update the index. Your change would > require storing an index entry for every record version. > > When garbage collecting, InterBase checks to see if there's another > version of the record with the key value from the version that's > going away. If so, it ignores that garbage collection pass. > > A better solution, in my opinion, would be to propagate record numbers > up the tree. Same length, already in the leaf level, makes every > index entry unique. Ответ Starkey: > Index garbage collection works this way: > > 1. For each record to be garbage collected a linked list > representing all versions is computed. > > 2. For each index defined on that table loop throught > the record versions to be deleted. If any version > has a value for the index not represented in the > list of records staying, remove those index entries > from the index. > > 3. Do about the same thing for blob pointers. > > 3. Zap the back pointer of the oldest surviving record. > > 4. Clean up the now orphan back versions on disk. > > (I don't actually remember whether the data pages or index/blob > garbage collection happens first). > > >Why I'm talking about it: other servers (Oracle and MS) uses index scan to > >calculate record count. It is easy way even for > >select count(*) from sometable, because there are less pages in index than > >in table, and scanning index pages will be much faster than scanning data > pages. > >But, you see, index key does not have transaction id, and IB can't understand > >what key versions can be seen by some transaction. > >Slow garbage collection is another point of the same issue, I think. > > The multi-generational nature of Firebird requires that the record > be visited to determine its state relative to your transaction, so > nothing is gained by walking the index rather than the pointer pages. > (Actually a minor de-optimization.) Вот. -- Dmitry Kuzmenko, Epsylon Technologies. TechSupport Manager. InterBase support. Welcome to http://ib.demo.ru/ (1251) (095) 530-28-06. Отправлено через сервер Talk.Ru - http://www.talk.ru --- ifmail v.2.15dev5 * Origin: Epsylon Technologies (2:5020/400) Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
Архивное /su.dbms.sql/21088dc116c3.html, оценка из 5, голосов 10
|
|
|