|
I completed this prototype and made it available in the first three patch sets of https://mongodbcr.appspot.com/504440019/. This patch changes $unwind execution so that it is always done by delegating to a new UnwindStage, which implements the PlanStage interface. (I chose $unwind as an arbitrary guinea pig stage. It shouldn't be special.) Further work will be required to fully pushdown $unwind into the PlanStage layer; this will be prototyped under WRITING-4137.
There are two major problems which we should discuss around this POC:
- The strategy for DocumentSourcePlanStage is to ensure that the underlying PlanStage as a special queue stage as its child. It calls next() on the child plan stage, populates this queue, and then allows the PlanStage to draw these results out of the queue by calling work() on its child. Is there any way to simplify this strategy in an intermediate world in which we still have DocumentSources delegating their work to PlanStages?
- The library containing the DocumentSources cannot depend on the 'query_exec' library in its current form, since 'query_exec' has a large dependency set, many of which are mongod-specific. We have two proposed approaches for dealing with this:
- Introduce MongoProcessInterface or a similar concept into PlanStages.
- Split the query exec library into separate libraries for code that is mongod-specific, mongos-specific, or common. Make the StageBuilder an interface, with different concrete implementations on the ServiceContext for mongod and mongos. The concrete stage builder implementations depend directly on the context-specific execution libraries. However, make an interface for "virtual collections" to prevent the query execution layer from depending on arbitrary subsystems.
pawel.terlecki do you think it would be useful to share this work at this early stage, or should we wait until a more concerted design effort for this project is underway?
|