First off all, maybe this message was send to wrong list. Sorry.

Some time ago, I ask Adriano about a possible multi-thread
optimization in Firebird Server.

I talk with him about the index restoration in gbak, where one table
have (in most cases) more than a index, and in P2 or P4 systems, only
one core/processor is used.

If you have a good RAID system, this CPU will be stressed while all
another is near a deep-sleeping.

example: restoring a 20GB database, is need less than 15 min to
restore all tables, and near 40 min to create indexes. Only for a
small comparison, running two gbak restores with the same gbk file,
with different names off coarse, was finished in less than 1h15 min.
(increased near 40% in index restore)

In Classic or SuperClassic, why is not possible start a index creation
process in another thread (for each index in that table), and continue
read the "stream" of gbaked file ?

or, in a select <fields> from <table_A> union all select <fields> from
<table_B>, maybe is possible to run each union node in a separated
thread, running the order by after Sync this threads ?

And the merge/sort step... isn't a good idea to segment this operation
in several threads ? (Ok, this probably will need a pool of "sort
threads" to produce some performance gain).

And thanks all for the good job in Firebird!

sincerely,

Eduardo Jedliczka
Brazil