| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
Remove leading comments that are just stating the filename.
Move any file-level comments below the copyright banner.
Remove leading blank lines.
|
| |
|
|
|
|
| |
file per spill to disk
|
| |
|
| |
|
|
|
|
| |
allowDiskUse is false
|
| |
|
|
|
|
|
|
|
|
|
| |
Merges the three parallel vectors in DocumentSourceGroup and
DocumentSourceBucketAuto into one vector of AccumulationStatements.
Closes #1143
Signed-off-by: Charlie Swanson <charlie.swanson@mongodb.com>
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Ensures that a collection lock is held in at least MODE_IS while
deregistering a PlanExecutor from the cursor manager. Introduces new
PlanExecutor::dispose() and ClientCursor::dispose() methods that must be
called before destruction of those classes, and ensures they are called
before destruction. These calls will thread an OperationContext all the
way through to DocumentSource::dispose() for each stage in a Pipeline,
which will give DocumentSourceCursor a chance to acquire locks and
deregister its PlanExecutor if necessary.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
explain
Like other explainable commands, aggregate can now be
explained using the explain command, e.g.
db.runCommand({explain: {aggregate: ...}, verbosity:
"executionStats"}). The existing explain:true flag
corresponds to "queryPlanner" mode and is still supported.
However, explain:true cannot be specified when explaining
aggregate via the explain command.
Additional execution information is provided only in the
$cursor section of the aggregation explain output. Having
aggregation stages themselves track and report execution
info is further work.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
These methods were formally used to propagate a new ExpressionContext to
stages, accumulators, or expressions which potentially needed to
comparisons. Originally, this was necessary since Pipeline parsing
happened outside of the collection lock and thus could not determine if
there was a default collation on the collection. This meant that the
collation could change after parsing and any operators that might
compare strings would need to know about it.
We have since moved parsing within the lock, so the collation can be
known at parse time and the ExpressionContext should not change. This
patch requires an ExpressionContext at construction time, and disallows
changing the collation on an ExpressionContext.
|
| |
|
|
|
|
|
|
| |
This provides a way to do pre-parse validity checks. Full
parsing of the Pipeline must be done under the collection
lock, when the collation is known.
|
| |
|
|
|
|
|
| |
This will make it easier to add tests that each DocumentSource
correctly handles a paused input.
|
|
|
|
|
| |
This approach removes the need to buffer all documents in memory, thus
removing concerns about spilling intermediate results to disk.
|
| |
|
|
|