Den 2012-09-12 00:20 skrev Dmitry Kuzmenko såhär: > I think here OS cache is more sufficient, especially for databases > that bigger than RAM. Here one thought came to me, that was inspired > by Vlad Horsun - to restore all indices per table, table by table, not > that way like gbak restores indices in current versions (all foreign > keys goes at the end).
In regular DB use (not restore), when multiple indices are created in a single transaction, will FB read through the data pages once for each index creating them serially, or will it read the data pages once for all indices, creating them, so to say, in parallel (not meaning multiple threads or anything)? I'm thinking that reading the data pages once for multiple indices would be beneficial not only for DB restore, but the same mechanism should be possible to use whenever multiple indices are created in a single transaction. Kjell -- -------------------------------------- Kjell Rilbe DataDIA AB E-post: kj...@datadia.se Telefon: 08-761 06 55 Mobil: 0733-44 24 64 ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
