On Thu, May 26, 2016 at 8:30 AM, fabia...@itbizolutions.com.au [firebird-support] <firebird-support@yahoogroups.com> wrote:
> > I wrote: > > > In V3.0, Firebird is multi-threaded at the client statement level. It > does not decompose queries and schedule the pieces on different processors. > > > > I understand, I thought true SMP was referring to assigning each client's > request to all CPU at once, instead of balancing the clients requests > across processors. So the current version (FB 3) is probably going to > outperform the FB 2.54 when there are concurrent requests passed to the > server engine because each request will go to a different processor, > correct? The more concurrent requests we have the more we are going to > notice the difference, right? > Right. The strength of a relational database is its ability to process multiple client requests simultaneously. That's the goal of Firebird V3. If all you want to do is strip data off the disk as fast as possible, there are better technologies. Splitting client requests across processors in general is hard. Well, it's less hard if you don't care if the result is performance improvement. In general, splitting a single requests across processors is beneficial if there's lots of computing or if the request can be split so different parts access different disks. A simple "select count(*) from MyTable" cannot be improved by splitting it across processors unless the table can also be split across disks in a deterministic way. On example that could be improved by splitting a single request is large sorts, which can be improved by splitting them so one thread is fetching records while others sort subsets. With large memories and 64 bit address spaces, lots of sorting can happen in memory. But frankly, if I were the core developers, I'd want to put my efforts into other areas that will provide more benefits than fast large sorts. Good luck, Ann
