Thomas, > I'm currently running a restore of a Firebird 2.5.2 TPC-H scale 1 database > (both, backup and restore are on a consumer SDD) and in that case the index > creation process is mainly CPU bound, basically fully utilizing 1 core of my > hexa-core desktop.
Are you testing using IB XE3? Being CPU bound is what I would expect. > Is this something where Firebird could benefit as well? If yes, would this be > possible across all architectures or does this need a shared page cache etc. Yes, this is something that FB could benefit from. Yes, it should be possible across all architectures. No, it should not require a shared page cache. I don't think the cache factors into it. > Another improvement for the index creation process during a restore might > be to allow a temporary bigger page cache, so perhaps a -cache, -buffers or > whatever option might be helpful. Pretty much what e.g isql already allows at > connection level etc. I don't see how a larger cache or more buffers would help the index creation process. The ideal process would have a single pass of a table collect data from columns in all indexes, into a temporary file (or multiple), then pass that data to appropriate sorting/index create routines. In which case, the number of pages not going to make a significant difference because each page would be read only once. The cache is beneficial when multiple page accesses are involved. Sean ------------------------------------------------------------------------------ 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
