Re: Informix and Oracle in the same shop

In article <5n4f08$cq9@agate.berkeley.edu>, pbrown@triplerock.CS.Berkeley.EDU writes: > 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; Do we need a drum roll? > 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. Okay, let's stop here... is DSA using any of these models. Not that I'm aware of. > 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). Hence POSIX and/or DCE. > Now, this is fine for most systems, but for DBMSs there are > advantages to controlling *as much as possible* when this is > done. Unfortunately, unless the RDBMS engine is running as root, it is also treated as a user process and thus can be preempted. Also, even if it's running as root, it needs to run in a non-preemptive queue for it to relinquish the processor cooperatively. It's an all or nothing game. Either you're going to be able to "control your destiny and relinquish" or expect to be preempted and program for that. > Sometimes, the DBMS would like to schedule an asynchronous > operation (IO) and then do something else without the expense of > a context switch. Depending on how aio is implemented. If aio is implemented using user level aio, then the request is handed off to the aio subsystem which has its own set of processes. > Or the engine knows it's about to enter a > really tight loop and would rather not be stopped and > re-started. As stated above, the process can only control this if it's in a non-preemptive queue. > Or in an SMP architecture, the DBMS would like to > load balance based on data demand, not time-slices. I don't understand your statement here. In an SMP arch you'll have your l2 caches hopefully reaching a working set for their instruction and data sets. > 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. As I mentioned in a previous post, this is arguable. > (Ever heard of a transactional Unix file-system?) Journaled file system: XFS, JFS... > 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. ... and that *is* my point! None of them do it but they make this claim that isn't quite true. > 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. Please expand on this if you will... > Now, for a discussion about the relative merits of each vendor's > approach to multi-threading . . . This contradicts what you've just written: 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. Let's not confuse the two... -- Pablo Sanchez | wk: 415.933.3812| pg: 800.930.5635 -or- pablo_p@pager.sgi.com --------------+-----------------+-------------------------------------------- pablo@sgi.com ... when mailing me, place "not spam" in the Subject