When you have only one query with one source, scheduling is not a thing to think about, in other cases some options can be done by configuring the scheduler.
Scheduling in Odysseus has two parts:
In ODYSSEUS_HOME a file called scheduling.conf defines the basic scheduling mechanisms:
The scheduling can be changed via Odysseus Script (Other Commands).
#SCHEDULER "Single Thread Scheduler RR" "Round Robin"
Remark: This will not update scheduling.conf file.
Scheduler.Simplethreaded.SourcesPerThread) how many sources should be scheduled by one thread. If more sources need to be scheduled a new thread is spawned.
Scheduler.Simplethreaded.SourceThreadCount), independed of the number of sources
Remark: The configuration is done in Odysseus.conf. It is also possible to use Odysseus Script (#ODYSSEUS_PARAM see Other Commands).
In the following example the "ST Scheduler RR MS Limit Thread" scheduler is used with the "Round Robin" scheduling strategy. The following parameter states, that there should be one source per thread, i.e. each source in a query gets its own thread and will run independently.
#SCHEDULER "ST Scheduler RR MS Limit Thread" "Round Robin" #ODYSSEUS_PARAM Scheduler.Simplethreaded.SourcesPerThread 1
The following configurations can be done in the Odysseus.conf:
Other, non core schedulers could provide further parameters.
There are some features, that provide further schedulers
By the scheduling strategy, the query is separated into parts, that could be scheduled independently. Only if a query contains at least one Buffer operator, the scheduling strategy is relevant. In other cases, this strategy does not make any difference.
Remark: If there are no multiple threads, then the processing is done from a source until a sink. If an operator has more than one outputs, the order is from left to the right, but always until a sink. So if one output port is connected to a query part that has a large number of following operators (or an operator that has a high latency) this will block the execution of the other output port until each part after the port is exeucuted. You could add Buffer operators after each output to allow parallel execution of each output line.
List of currently available Scheduling Strategies (Availablity depends on contained bundles):
See http://cs.brown.edu/research/aurora/vldb03_scheduler.pdf for deeper information about Aurora based schedulings
See http://i.stanford.edu/~dilys/papers/vldb132.pdf for deeper information about Chain Scheduling
You could also bypass all scheduling strategies, even with buffers, when using a threaded buffer (see Buffer operator) and let the virtual machine/operating system do the thread handling. In many cases this is faster than using a strategy.