Re: Informix and Oracle in the same shop

Pablo Sanchez wrote: : The Informix Online engine is not multithreaded. It's some : bastardization of threading. It's a nice concept but it still incurs : overhead. From the top; a. This whole discussion confuses 'threads' as an OS feature, with the idea of 'threads' as an execution context. You can implement a threaded system either by using the OS thread facilities, or by using a library. For example, the Java VM is multi-threaded yet does not use any OS level threading facilities. DSA does not use the operating system's thread facilities. This does not mean that it isn't 'multi-threaded'. There are a number of really efficient 'thread libraries' out there (Mach, Plan-9) which DBMS engineers can take and modify. b. There are profound dis-advantages to using any of the OS thread facilities in a DBMS. First, there are subtle differences between thread semantics (more profound between NT and Unix). To minimize the inter-OS differences (read: porting complexity) most DBMSs do their own threading. Secondly, all OS's do thread management pre-emptively. At time-slice intervals, the OS traps out and imposes a context switch. Now, this is fine for most systems, but for DBMSs there are advantages to controlling *as much as possible* when this is done. Sometimes, the DBMS would like to schedule an asynchronous operation (IO) and then do something else without the expense of a context switch. Or the engine knows it's about to enter a really tight loop and would rather not be stopped and re-started. Or in an SMP architecture, the DBMS would like to load balance based on data demand, not time-slices. Basicly, the DBMS knows a lot about what it needs to do and how it needs to do it. The OS has a more general purpose. It's true that there is some overhead in 'doing threading yourself', and it isn't perfect (the dang OS will *still** slice you out) but the overhead is more than compensated for by the advantages you get. c. A DBMS is not an operating system. DBMSs have more specialist tasks, and more demanding quality-of-service guarantees. (Ever heard of a transactional Unix file-system?) A lot of the good ideas from OS stuff has found its way into DBMS under-pinnings, but there are *tonnes* of things the OS doesn't do, that no one else needs, that DBMSs have to manage. If you want to define 'multi-threaded' as 'uses the OS thread facilities' then to my knowledge none of the DBMSs out there (except possibly Tandem on Guardian and IBM's MVS DB/2) are multi-threaded. I hate to point it out to Pablo, but OS's in general aren't particularly nice environments to write DBMSs in. That's fine; it's not the OS's job to make the DBMS engineer's life easy. I suggest you read; Stonebraker, M. "Operating System Support for Database Management" Re-printed in _Readings_in_Database_Systems_. McKusick, Marshall Kirk et al. _The_Design_and_Implementation_of_the_ 4.4_BSB_Operating_System_ Addison Wesley, 1996. (Particularly the sections in chapter 4 on OS kernel process/thread management). There is also extensive literature on operating system support for threads or 'lightweight processes'. Now, for a discussion about the relative merits of each vendor's approach to multi-threading . . . KR Pb