Skip to content

AdminAsya Kamsky (Principal Engineer, Office of CTO, MongoDB)

My feedback

3 results found

  1. 26 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    An error occurred while saving the comment

    There's already an internal parameter that is available to change this value but I want to make it clear that the 100MBs limit only applies to in-memory sorts and in-memory groups (which are basically like in-memory sorts). To make aggregations faster, making sure that large sorts are supported by an index or can be avoided entirely would be preferable to changing this parameter limit.

    More discussion of the limit is here: https://developer.mongodb.com/community/forums/t/mongodb-meaning-of-pipeline-aggregation-100mb-limit/99553/2

  2. 4 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    1 comment  ·  Database  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    An error occurred while saving the comment
    AdminAsya Kamsky (Principal Engineer, Office of CTO, MongoDB) commented  · 

    When you're doing aggregation for this, it doesn't know to use an index - you would need to add `hint` or `$sort` to make it use an index. That's likely to make it faster (though it still wouldn't use the superior DISTINCT_SCAN plan, it will use a covered IXSCAN).

  3. 4 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    1 comment  ·  Database  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    An error occurred while saving the comment

    The issue with arbiters is they do not accept writes and therefore cannot contribute to majority write concern acknowledgement which distributed transactions rely on.

    There is no plan at this point to allow distributed transactions with arbiter.

    As a side note, PSSA is a bad configuration to have since having four nodes means majority is three and therefore it doesn't give you any advantage over PSS cluster. Both can only acknowledge majority write concern writes when at most one data holding node is down. With one secondary gone, PSS cluster still has majority available. No reason to ever use PSSA that I can see.

Feedback and Knowledge Base