> 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
------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
