All, It's expected that GBAK restores a database in the faster possible way. It creates BLR, uses low level API and is built by people that know the internals. :-)
But it does wrong! There is a simple change which makes it much faster, tested with Linux 2.5 embedded restore: Two databases, with two different tables filled with 2,000,000 records: create table t1 (n1 integer); create table t10 (n1 integer, n2 integer, n3 integer, ..., n10 integer); ---------------------- Restore timings: T1: 14.5s T10: 20.5s Improved gbak timings: T1: 9.7s T10: 14.7s ---------------------- GBAK builts a BLR in the following way: blr_receive blr_store ... Then calls isc_start_and_send N (records) time. My change creates this BLR: blr_loop blr_receive blr_store ... Calls isc_start_and_send first time then N-1 isc_send. I suppose this works in all GBAK versions. Adriano PS: There is other restore improvement capable of take down time from around 8.5s to 0.5s over TCP, but it still requires some analisys. ------------------------------------------------------------------------------ Xperia(TM) PLAY It's a major breakthrough. An authentic gaming smartphone on the nation's most reliable network. And it wants your games. http://p.sf.net/sfu/verizon-sfdev Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
