Kjell Rilbe wrote:

>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.
>
>Kjell
>
>

Kjell,

FB SS has a shared cache, so, any read page will be in cache (for a
while at least :-) ) and will be available for any connection.
in CS the cache are by connection, so the page will be in cache, but if
connection 1 read page 10, then connection 2 needs page 10 too,
connection 2 will read it from disk, and the keep it copy on it's
individual cache. (The SO cache has a big advantage in FB CS, since
connection 1 reads page 10, and then connection 2 asks for it again,
there is a big chance that this page will be in the SO cache avoiding a
physical read).

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.

The best I can think of is:
Has a big amount of RAM to keep the maximum number of pages in cache (be
it FB cache or SO cache)

see you !

--

Alexandre Benson Smith
Development
THOR Software e Comercial Ltda.
Santo Andre - Sao Paulo - Brazil
www.thorsoftware.com.br



--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.322 / Virus Database: 267.2.0 - Release Date: 27/05/2005