[SERVER-84873] Investigate performance of artificial SSB query Created: 27/Oct/22  Updated: 12/Jan/24  Resolved: 06/Jan/23

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Task Priority: Major - P3
Reporter: Colby Ing Assignee: Mohammad Dashti (Inactive)
Resolution: Incomplete Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
depends on SERVER-70726 Support pushing down as per-path filt... Closed
Participants:

 Description   

db.order_lineitem.aggregate([
    {
        $match: {
            $and: [
                { "order.o_orderdate": { $gte: ISODate("1992-01-01") } },
                { "order.o_orderdate": { $lte: ISODate("1996-01-01") } },
            ]
        },
    },
    {
        $group: {
                _id: "$order.o_orderkey",
                priority: { $last: "$order"},
                someSum: {
                    $sum: "$l_extendedprice"
                },
                anotherSum1: {
                    $sum: "$l_discount"
                },
                anotherSum2: {
                    $sum: "$l_tax"
                },
                anotherSum3: {
                    $sum: "$l_quantity"
                },
                count: { $sum: 1 }
            }
        }
    ]

  • Investigate perf, see if there's any low-hanging fruit
  • if no low hanging fruit, I'd still like to understand where all the time is spent in this query

 



 Comments   
Comment by Mohammad Dashti (Inactive) [ 03/Nov/22 ]

colby.ing@mongodb.com apparently, the main issue is with SERVER-70726, as we have an AND operator that filters the same order.o_orderdate path and this kind of filter is not currently supported to be pushed-down. Let's retry this ticket when SERVER-70726 is done.

Generated at Thu Feb 08 06:56:13 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.