Subject | Re: [firebird-support] Firebird 2.0 Indexing |
---|---|
Author | Kjell Rilbe |
Post date | 2005-05-29T19:44:25Z |
Alexandre Benson Smith wrote:
look on disk. The in-memory version could hold extra cached info such as
this transaction info for quick and easy access. In case the index page
is in cache but the data page isn't, this would save a lot of time. But
I do realize there are downsides. Probably lot's of'em! :-)
Kjell
--
--------------------------------------
Kjell Rilbe
Adressmarknaden AM AB
E-post: kjell.rilbe@...
Telefon: 08-761 06 55
Mobil: 0733-44 24 64
> Kjell Rilbe wrote:Ah, but the cached index page does not have to be identical with how it
>>Alexandre Benson Smith wrote:
>>>[snip] FB can't just use indexes
>>>for lookup values, it has to go to the datapage to see if that record
>>>are visible or not to the current transaction.
>>
>>Does FB cache this info in any way? I realize it might not be a good
>>idea for lots of reasons but I can also imagine that with an ingenious
>>solution it just might be a good idea after all. So, I'm curios how it's
>>done today and if there are any future plans in this area.
>
> Because of the MGA, FB *has* to go to the datapages to look for
> transaction status, to store the transaction information on the index
> pages too has a lot of disavantages, the index page will contain fewer
> index entries, when a transaction commits or rolls back the index page
> will need to be upated to, that will make the system slower.
look on disk. The in-memory version could hold extra cached info such as
this transaction info for quick and easy access. In case the index page
is in cache but the data page isn't, this would save a lot of time. But
I do realize there are downsides. Probably lot's of'em! :-)
Kjell
--
--------------------------------------
Kjell Rilbe
Adressmarknaden AM AB
E-post: kjell.rilbe@...
Telefon: 08-761 06 55
Mobil: 0733-44 24 64