Re: [Firebird-devel] RFC: Data page allocation algorithm

[Vlad K. <hv...@us...>]

> I'm not sure this will change much.  It will reduce the number of times 
> that the PIP needs to be referenced, which will save a little CPU.

    Also it will lower concurrency on PIP pages. Of course, common level of 
concurrency will not became much lower, but anyway...
  
> Careful write needs to be preserved in all cases, so the PIP will always 
> need to be written before the data pages and associated pointer pages.  
> But since all allocated data pages are lower in precedence than the PIP, 
> the PIP won't be forced out until a data page needs to be written, so it 
> is unlikely that the PIP will be written multiple times using either scheme.

    You are missed Classic architecture - without shared cache data pages
often written in downgrade calls and it forces write of all higher precedence 
pages. 
 
> There may well be some benefit to allocating data pages contiguously 
> when the database page size is smaller than the OS page size which, 
> presumably, is usually the case.

    Consider also RAID block size. Often it is much more than our default\
preferable page size of 4-8 KB

> I did do some experiments quite some time ago with prefetching (for 
> which system I frankly don't remember).  The results were sufficiently 
> disappointing that I gave it up.  The fundamental problem is that 
> fetching things that you don't need interferes with fetching things that 
> you do.  Predicting exactly what you will need next is really quite 
> difficult.  Guessing wrong is significantly worse than not guessing at 
> all.  Probably.

    I told about prefetch by OS which is out of our control but almost always
present. 

    As for prefetch by Firebird engine itself - we have some ability to
predict page access sequence:
- natural scan (sweep and gbak backup as cases of natural scan)
- blob read
- less effective, but anyway - index scan when key range is relatively big
   we can prefetch pages from leaf level and then, using record numbers
   bitmap we can prefetch data pages
- nbackup backup
I have some of this implemented with some success and defeats but 
currently it is to early to say about results.

    But let's return back to the extents theme :)
 
> What might be a better thing to explore is an extent based allocation 
> mechanism.   It probably could be made to reduce both allocations and 
> references to the allocation pages,  though it would probably be a 
> relatively large architectural change

    Here i probably lost you - are you agreed with proposed changes ? Or
you support the idea but offer to base it on some different mechanism 
(such as replace PIP with something like Extents Allocation Bitmap)?

> -- and one difficult to migrate to 
> without a full dump and reload.

    My patch with extents changes ODS but this is ok for FB3 until we 
not released beta version. 
 
Thanks for the opinion,
Vlad