Fix unique document count for projected samples

ExportXMLWordPrintableJSON

    • Type: Bug
    • Resolution: Unresolved
    • Priority: Major - P3
    • None
    • Affects Version/s: None
    • Component/s: None
    • Query Optimization
    • ALL
    • Hide 
      for (let i = 0; i < 1000; i++) docs.push({e: 1, b: i});
coll.createIndex({e: 1, b: 1});
coll.find({e: {$gte: 1}, b: 5}).explain("executionStats");
// indexSeekEstimate: 1000, actual seeks: 2
      Show
      for (let i = 0; i < 1000; i++) docs.push({e: 1, b: i}); coll.createIndex({e: 1, b: 1}); coll.find({e: {$gte: 1}, b: 5}).explain( "executionStats" ); // indexSeekEstimate: 1000, actual seeks: 2
    • None
    • None
    • None
    • None
    • None
    • None
    • None

      countUniqueDocuments counts distinct _id values, but CBR samples that are projected without _id, result in the count of 1.

      In SamplingEstimatorImpl::estimateNDV, a sample NDV of 1  combined with 1 unique document triggers the early return for unique fields, which returns the collection cardinality. This affects `estimateIndexSeeks` estimates.

      Join samples are not projected today, so the join optimizer is not affected.

      Proposed fix

      Count distinct sampled documents by RecordId when the sample is generated on the fly, and by _id when a persisted sample is loaded (persisted samples are stored without projection).

            Assignee:
            Milena Ivanova
            Reporter:
            Milena Ivanova
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated: