Hello, Sean! Tuesday, September 11, 2012, 8:11:20 PM, you wrote:
>> >> In sum, according to trace: While the 75 page buffers restore took >> >> 601030ms, the 100000 page buffers restore took 375253ms. LS> Interesting. LS> Could you try one more test, with cache size = 40,000. I did restore test for some production database, and found no difference for db cache from 1k to 16k. http://www.ibase.ru/devinfo/rs-win-se-cache.gif -i - index creation turned of. So, I do not see difference in it neither for tables, nor for indices. TS> With a higher page cache, one can see in Task Manager a steady increase TS> of RAM usage while restoring records, which *might* get re-used during TS> index creation, because it doesn't need to pull data pages from the disk TS> again when creating the index. 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). -- Dmitry Kuzmenko, www.ibase.ru, (495) 953-13-34 ------------------------------------------------------------------------------ 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
