Join Firebird!

Join Firebird Foundation to support Firebird SQL development and receive multiple bonuses

Follow Us

Select your media preference

Newsletter

Subscribe to Firebird’s Newsletter to receive the latest news

Developer's Report: Firebird Core Development
July 2012 to January 2013
 
I didn't describe here planned features\improvements. Only what was more or less done.
 

1. Changed page allocation algorithm

I'm going to describe it in details in fb-devel in the next few days, so here is just a short description.
The main goal is to reduce data fragmentation at db-file level. To do it, i offer to allocate pages not one-by-one (as currently) but in groups of 8 contiguous pages (extents).Of course such allocations will be applied only when needed, mostly for a data pages. Allocations of pages for blob data also could be grouped but amount of allocation unit could be any number of pages (not necesary 8).

This is not a new invention, i took this idea from MSSQL's ODS. It should make prefetch (at OS-level or native) more efficient and speed up the filling of  a cold page cache with valuable data.
 
This feature is almost ready to be committed, currently i'm actively testing it and evaluating performance effects. As it affects the ODS, it would preferable if it were committed before the alpha.

2. Asyncronous and multi-block disk IO, prefetch of pages for natural scans and so on

This feature is implemented for disk reads and i'm looking what can be done for disk writes too. Testing and some platform dependent adaptation is needed.  (The implementation was tested briefly on Windows and Linux.)

3.  On-line and partial validation

Ability to validate a database without exclusive access to it. Main goal is to allow validation of particular table(s) and (not necessary) indices without locking whole database. Only currently validated table is locked for shared read (i.e. it is available for SELECTs during validation). Not all checks is possible in this mode, for example orphan pages couldn't be detected.
 
This feature was implemented some time ago in the v2.5 codebase and  is waiting to be ported forward to the v3 code.

4.  Ability to make concurrent attachments work in common

For Superserver only, the idea is for major work to be allocated to concurrent attachments to be processed as a whole, for example: group commit.  Some research is under way, no final results yet.

5.  Improve DLL unload on Windows

DLL unload on Windows is a  very tricky process. In FB3 we now using an embedded engine (i.e. DLL) and it could freeze process when DLL is unloaded (i have such cases). This issue is investigated currently and a solution is searched for it.

Vladyslav Khorsun
Dnetpropetrovsk, Ukraine
July 2012 to January 2013
 
I didn't describe here planned features\improvements. Only what was more or less done.
 

1. Changed page allocation algorithm

I'm going to describe it in details in fb-devel in the next few days, so here is just a short description.
The main goal is to reduce data fragmentation at db-file level. To do it, i offer to allocate pages not one-by-one (as currently) but in groups of 8 contiguous pages (extents).Of course such allocations will be applied only when needed, mostly for a data pages. Allocations of pages for blob data also could be grouped but amount of allocation unit could be any number of pages (not necesary 8).

This is not a new invention, i took this idea from MSSQL's ODS. It should make prefetch (at OS-level or native) more efficient and speed up the filling of  a cold page cache with valuable data.
 
This feature is almost ready to be committed, currently i'm actively testing it and evaluating performance effects. As it affects the ODS, it would preferable if it were committed before the alpha.

2. Asyncronous and multi-block disk IO, prefetch of pages for natural scans and so on

This feature is implemented for disk reads and i'm looking what can be done for disk writes too. Testing and some platform dependent adaptation is needed.  (The implementation was tested briefly on Windows and Linux.)

3.  On-line and partial validation

Ability to validate a database without exclusive access to it. Main goal is to allow validation of particular table(s) and (not necessary) indices without locking whole database. Only currently validated table is locked for shared read (i.e. it is available for SELECTs during validation). Not all checks is possible in this mode, for example orphan pages couldn't be detected.
 
This feature was implemented some time ago in the v2.5 codebase and  is waiting to be ported forward to the v3 code.

4.  Ability to make concurrent attachments work in common

For Superserver only, the idea is for major work to be allocated to concurrent attachments to be processed as a whole, for example: group commit.  Some research is under way, no final results yet.

5.  Improve DLL unload on Windows

DLL unload on Windows is a  very tricky process. In FB3 we now using an embedded engine (i.e. DLL) and it could freeze process when DLL is unloaded (i have such cases). This issue is investigated currently and a solution is searched for it.

Vladyslav Khorsun
Dnetpropetrovsk, Ukraine