December 2013 - January 2014
December 2013
- Found ability for DoS attack when run script with a lot of connect commands with invalid password:
there was no delay ~5-7 seconds between such attempts on some cases of config parameters
Result: confirmed and fixed by Alex Peshkoff
- Descending indexes can be very inefficient in lookup/scan (found while testing INSERT performance)
Result: CORE-4302, fixed by Vlad Khorsun
- Re-checked some old queries on which FB v3 had problems before (CORE-4261, etc)
Result: no problems anymore, a few performance related questions directed to Dmitry Yemanov
- FB hangs on preparing of some queries, unable to establish new connect or asking MON$ tables during such prepare
Result: confirmed by Dmitry Yemanov
- FB crashes when attempt to solve Einstein task (too complex 'where' condition)
Result: CORE-4293, fixed by Dmitry Yemanov
- Resumed comparing results FB vs MS SQL vs ORA on misc. queries
Result: found that recursive CTE member can not be referred inside derived table, no explanation yet
- Engine crashes when attempt to recreate table with FK after syntax error before such recreating
Result: CORE-4304
- Poor performance of LIKE operator when when declared length of varchar field is long (e.g 32760) but string and pattern are both short ('q' and '%q%')
Result: CORE-4306
- Tested special build ("RFC: Data page allocation algorithm" by Vlad Khorsun)
Result: server crashes when nbackup is running during updates, validation errors when DML was interrupted via kill (reported to Vlad Khorsun)
- Found some issues about cursor stability during update tables (results mismatches with other RDBMS)
Result: test cases added to CORE-3362, regression is fixed by Vlad Khorsun
January 2014
- Continued testing special build ("RFC: Data page allocation algorithm" by Vlad Khorsun)
Result: number of nbackup related errors were found, reported to Vlad Khorsun
- Heavy-load test after applying Vlad's patch about page allocation (extents)
Result: no errors in SS, deadlock encountered in CS after ~9 hours of running
- Tested the extents build on a database with master-detail tables
Result: extents built is better in selects from single table and especially in hash joins
- Restore on LI-V2.5.3.26730 of production metadata (LI-V2.5.3.26546) was unexpectedly too long
Result: fixed by Dmitry Yemanov
- Benchmarked analytical functions performance (linux ext4 mount options (sync vs async) and tempfiles setting)
Result: performance noticably drops as soon as TempCacheLimit is exhausted, even when temp directory if mapped to /dev/shm
- Benchmarked hash join in v3.0 vs merge join in v2.5; also hash vs nested loops (both in v3.0)
Result: found some cases when hash join loses in performance, reported to Dmitry Yemanov
- Server crashed with coredump at the disconnection time
Result: reported to Dmitry Yemanov, stack traces are provided
- Deadlock while 10 connections are simultaneously querying MON$DATABASE and the database is under high load
Result: reported to Dmitry Yemanov, stack traces are provided
- Benchmarked restoring of big database (48 Gb) on v2.5 vs v3.0, with and without services
Result: v2.5 without services is extremely slow, times are equal when services are used
- Benchmarked parallel inserts from 10 isqls, v3.0 vs v2.5 (both in SuperClassic)
Result: v3.0 is faster than v2.5 when inserting 10^6 rows (no indexes, no sequences)
Pavel Zotov
Moscow, Russian Federation
December 2013 - January 2014
December 2013
- Found ability for DoS attack when run script with a lot of connect commands with invalid password:
there was no delay ~5-7 seconds between such attempts on some cases of config parameters
Result: confirmed and fixed by Alex Peshkoff
- Descending indexes can be very inefficient in lookup/scan (found while testing INSERT performance)
Result: CORE-4302, fixed by Vlad Khorsun
- Re-checked some old queries on which FB v3 had problems before (CORE-4261, etc)
Result: no problems anymore, a few performance related questions directed to Dmitry Yemanov
- FB hangs on preparing of some queries, unable to establish new connect or asking MON$ tables during such prepare
Result: confirmed by Dmitry Yemanov
- FB crashes when attempt to solve Einstein task (too complex 'where' condition)
Result: CORE-4293, fixed by Dmitry Yemanov
- Resumed comparing results FB vs MS SQL vs ORA on misc. queries
Result: found that recursive CTE member can not be referred inside derived table, no explanation yet
- Engine crashes when attempt to recreate table with FK after syntax error before such recreating
Result: CORE-4304
- Poor performance of LIKE operator when when declared length of varchar field is long (e.g 32760) but string and pattern are both short ('q' and '%q%')
Result: CORE-4306
- Tested special build ("RFC: Data page allocation algorithm" by Vlad Khorsun)
Result: server crashes when nbackup is running during updates, validation errors when DML was interrupted via kill (reported to Vlad Khorsun)
- Found some issues about cursor stability during update tables (results mismatches with other RDBMS)
Result: test cases added to CORE-3362, regression is fixed by Vlad Khorsun
January 2014
- Continued testing special build ("RFC: Data page allocation algorithm" by Vlad Khorsun)
Result: number of nbackup related errors were found, reported to Vlad Khorsun
- Heavy-load test after applying Vlad's patch about page allocation (extents)
Result: no errors in SS, deadlock encountered in CS after ~9 hours of running
- Tested the extents build on a database with master-detail tables
Result: extents built is better in selects from single table and especially in hash joins
- Restore on LI-V2.5.3.26730 of production metadata (LI-V2.5.3.26546) was unexpectedly too long
Result: fixed by Dmitry Yemanov
- Benchmarked analytical functions performance (linux ext4 mount options (sync vs async) and tempfiles setting)
Result: performance noticably drops as soon as TempCacheLimit is exhausted, even when temp directory if mapped to /dev/shm
- Benchmarked hash join in v3.0 vs merge join in v2.5; also hash vs nested loops (both in v3.0)
Result: found some cases when hash join loses in performance, reported to Dmitry Yemanov
- Server crashed with coredump at the disconnection time
Result: reported to Dmitry Yemanov, stack traces are provided
- Deadlock while 10 connections are simultaneously querying MON$DATABASE and the database is under high load
Result: reported to Dmitry Yemanov, stack traces are provided
- Benchmarked restoring of big database (48 Gb) on v2.5 vs v3.0, with and without services
Result: v2.5 without services is extremely slow, times are equal when services are used
- Benchmarked parallel inserts from 10 isqls, v3.0 vs v2.5 (both in SuperClassic)
Result: v3.0 is faster than v2.5 when inserting 10^6 rows (no indexes, no sequences)
Pavel Zotov
Moscow, Russian Federation