Validation of 'true SMP support for Superserver' in Fb3.0 (run 10 isql, each count rows from big data source; watch for load volumes of CPU in `top` utility): Confirmed, all CPU cores are loaded

Regress check whether *all* bitmaps are used for each separate index when search condition is like: WHERE field_a = … and field_b starting with … and field_c starting with … (all fields: _a, _b, _c - have indexes); works OK, no regression found

Comparison of JOIN performance, data sources: 10 rows and 10E+07 rows (indexed) 2.5 vs 3.0: FB 3.0 was better: 5.5 vs 8.4 in earlier tests but now it is NOT true! Time is equal)

Check issue about unnecessary join when condition contains expression that similar to be resolved by compiler as FALSE (like join on 1=0) Fb 3.0: Poor. Firebird still included table that should not ever be processed in plan and under some conditions fetches from that table

Check issues about fetches when insert data in child tables that violates FK constraint, 2.5 vs 3: same for both 2.5 and 3.0

Check again: how long DML can ignore request in MON$-table to be stopped (or disconnect attachment); too long wait when FB performs rollbacks after cancelling bulk DML, 2.5 vs 3.0: same for both 2.5 and 3.0

Check select n01,count(*) cnt from tbig where n01 in(741,258,963) group by n01 for table tbig=10’000’000 rows (index on n01 present), increased page buffer up to maximum in 32bit: 128K pages, 2.5 vs 3.0: no changes in CPU time and statistics between 2.5 and 3.0

Test performance of windowed functions: lead(. . .)over(order by <indexed_field>) in comparison with old style: select a.id id_curr, (select first 1 id id_next from tr b where b.id>a.id order by id) from tr a order by id: Fb3 performs badly. Also performs badly in comparison with Oracle 10/11.

Check CORE-3362 (cursor stability - integral ticket of samples)

Check again new single sort when union hierarchy present, since 05-08-2013

Check again merge when more than one rows in join cond: CORE-2274: NOT FIXED YET

Check again issues about visibility of data for two transactions in the same connect (using GTT on commit preserve rows): OK when TIL = read_only + read_committed

Check again CORE-3340 (could insert duplicate in PK in autonom TX, leading to unrecoverable .fbk), 2.5 vs 3.0: OK on both FB 2.5 and 3.0

Check CORE-3977 (DELETE FROM MON$STATEMENTS does not interrupt a longish fetch in Fb 3.0: NOT yet solved on table with 10E9 rows. Made a new test for this issue and opened a new tracker ticket (CORE-4179: mon$tables cannot be queried while a few ISQLs are doing bulk updates of huge table)

Get strange ability to create collation for WIN1251 from UNICODE case insensitive, which does not work properly (Fb 3 – see core-4180)

Invalid number of indexed pages in report of validation (hundred of trillions)

Run test: gfix –shut full when bulk DMLs working. Check whether gfix is still async even when FW = ON: Hooray! gfix -shut now becomes SYNCHRONOUS and does not return to command prompt untill all rollbacks of DML are done.

Multiple rebuilds of Fb3 and runs with gdb to get stack traces for server hangs (perhaps from querying mon$-tables) and discussion about this with Alex and Vlad. All test cases have been sent to Vlad. No solution yet.