Re: Is a Multithreaded Ingres On the Horizon???

In article <dshapiro-180893123726_at_dshapiro.apple.com>, dshapiro_at_apple.com (David Shapiro) writes:
> Possible differences with other architectures:
> - One cannot set up the server to have more engines than cpu's. This could
> be good or bad. If you have more engines than cpus, the OS scheduler will
> obviously have to swap the processes, assuming all engines need cpu time.
> This means there will be queries stuck in the swapped out engine while the
> other engines work on their tasks. It seems that it would be better as
> Sybase has restricted it, since having the extra engine is only creating
> more work for the OS, and not allowing any more database througput. Other
> database vendors argue that the extra engines allow one to prioritize
> queries as the database scheduler sees them (whereby one sets the OS
> priority of the engines, so some engines get more cpu time than others.)
> This may work under architectures such as Ingres or Oracle, where I believe
> the clients can direct their queries to a specific engine, but this would
> only hinder Sybase's throughput because a low priority engine with a long
> running query would only hold locks longer and reduce througput. Plus, the
> clients cannot pick a specific engine to process their query (hence the
> 'virtual' name?)

There could be other advantages besides prioritizing. I have found that a single Ingres server can only seem to handle 2 queries at a time. We have had situations where 2 big queries (big being defined as queries which take many minutes to run) were running on the same server process at the same time. During this time, no other users could start any queries on this server and users just trying to connect could not connect. At the time we were running one DBMS server on a one-cpu machine. Having two big queries running effectively shut down the system for all the other users. Running multiple DBMS servers, even on a one-cpu machine, solved this problem. The machine may not run at 100% efficiency under these conditions, but a slightly slower than normal system is much better than a completely dead one. So, I regard the number of DBMS servers to be more a function of how many concurrent users you need to support rather than how many cpu's you have.

Robert Perlberg
Dean Witter Reynolds Inc., New York
dwrsun4!perl_at_murphy.com -or- philabs!dwrsun4!perl Received on Wed Sep 01 1993 - 23:45:15 CEST