 |
|
|
su.dbms.sql- SU.DBMS.SQL ------------------------------------------------------------------ From : Vladimir Pavlikov 2:5020/400 26 Feb 2001 16:51:58 To : All Subject : Re: индексы в ИБ -------------------------------------------------------------------------------- Hello! "Dmitry Kuzmenko" <dima@demo.ru> wrote: > > Ответ не принимается :( Отсутствие номера транзакций в индексе - один из > > самых больших обломов в 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.) За публикацию спасибо. -- Владимир Павликов. Отправлено через сервер Talk.Ru - http://www.talk.ru --- ifmail v.2.15dev5 * Origin: Fidolook Express 2.000 www.fidolook.da.ru (2:5020/400) Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
Архивное /su.dbms.sql/6488e0974f20.html, оценка из 5, голосов 10
|
|
|