> Hi Vlad,
>
>
>> In your example we see 7149 physical reads and 214192 times this pages
>> was
>> referenced by the engine. To read a record engine needs to access pointer
>> page and
>> (at least one) data page. You have ~100K records so we can explain ~200K
>> fetches.
>>
>>
> I think that when doing an exhaustive retrieval like this select count (*),
> Firebird doesn't go back to the pointer page for each record but reads
> every record on the page before it goes back to the pointer page, starting
> the page/line index entry 0. For an indexed read, it would reference the
> pointer page and the page/line index.
Unfortunately, it does. When record is read, data page is released and
should
be fetched again. It means access of pointer page first as after DP was
released
world could be changed and that DP could be released and even new DP could be
reallocated at the same slot.
Regards,
Vlad
PS Snapshot (concurrency) transaction guarantees that once read record could be
read again and will be the same. So, in theory, we can just re-read same data
page
when looking for next record. But read-committed transactions don't have such
guarantee and we must fetch PP first.
------------------------------------------------------------------------------
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
