On Wed, May 25, 2016 at 2:53 PM, Ann Harrison <aharri...@ibphoenix.com> wrote:
> On Wed, May 25, 2016 at 1:11 PM, fabia...@itbizolutions.com.au > [firebird-support] <firebird-support@yahoogroups.com> wrote: > >> >> Now on the flip side, the performance sucks, it is worst than with FB >> 2.54, and when looking at the task manager on windows it appears only one >> processor it doing the job, as if the code was not SMP enabled.... very >> strange. >> > > One possibility is that you're testing V3.0 SuperServer single user. In > V3.0, Firebird is multi-threaded at the client statement level. It does > not decompose queries and schedule the pieces on different processors. > That means that a full-table scan runs on only one processor. Two > simultaneous full-table scans will run on two processors. > I should have continued to say that two full-table scans probably won't be any faster in 3.0 than they were in 2.5 because you're measuring disk transfers and adding processors doesn't make the disk go faster. I might also have mentioned that sharing caches and other internal structures between simultaneous threads is one challenge. Distributing queries across processors is another and totally different challenge. The Firebird developers were wise (in my opinion) to take the challenges one at a time. Good luck, Ann
