[COMPASS-367] Configurable sample size Created: 17/Nov/16  Updated: 10/Jan/20  Resolved: 09/Jan/20

Status: Closed
Project: Compass
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Task Priority: Major - P3
Reporter: Anna Herlihy (Inactive) Assignee: Unassigned
Resolution: Won't Fix Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to COMPASS-422 mongodb-schema: provide a memory limi... Closed
Epic Link: COMPASS-2234

 Description   

From conversations at MDBE16 and intercom, many people want to either have larger or smaller sampling sizes since their queries are taking too long or the sample size is not statistically useful. Could be a part of progressive loading/sampling.



 Comments   
Comment by Brian Blevins [ 10/Jan/20 ]

 

Refer to the MongoDB Feedback Engine idea for this feature.

 

Comment by Githook User [ 30/Sep/18 ]

Author:

{'name': 'Lucas Hrabovsky', 'email': 'hrabovsky.lucas@gmail.com', 'username': 'imlucas'}

Message: COMPASS-367: Turn off sub_filter_last_modified

Intercom sends a proper etag anyway and turning this off will fix some HTTP caching issues customers hit when we change this config
Branch: master
https://github.com/10gen/compass-maps-server/commit/be59812c7e4ff62d8925dbf64f1dc1d2ec10b815

Comment by Githook User [ 30/Sep/18 ]

Author:

{'name': 'Lucas Hrabovsky', 'email': 'hrabovsky.lucas@gmail.com', 'username': 'imlucas'}

Message: COMPASS-367: Just hardcode tile host to avoid CSP clash with mongodb.sh
Branch: master
https://github.com/10gen/compass-maps-server/commit/bb5b3f058f4e7a29dd17d0e007a6153e6a69edc0

Comment by Sam Weaver [ 09/Mar/17 ]

Technically yes, it probably could be done by just removing the artificial limit of 1000 documents. Issues there would be:

1) The UI would probably never render and consume all available RAM unless we put in some kind of optimization
2) Users probably won't realize the cost of scanning over every document in their collection and annihilating their working set.
3) Could potentially run for days or weeks depending how big the DB is, how do we convey that to the user? What about if stuff changes signficantly over that time? Do we start again or gloss over the diffs? How do they abort?

It gets a bit gnarly to do this properly. This should really be part of an "incremental refinement" approach. Think where Expedia keeps putting cheaper prices in after the initial render.... Users should be able to abort at any time and just make do with the results that they have.

Comment by Peter Schmidt [ 08/Mar/17 ]

sam.weaver What's actually complicated about it? Could it be made actionable by just removing the artificial Compass limit of 1000 documents or is there more to this story that I'm not seeing (e.g. provide links to specific intercom conversations?)

Comment by Sam Weaver [ 07/Mar/17 ]

This is about having more than a 1000 document limit on the schema view. Some users want to scan the entire collection. It's not something we are going to work on anytime soon but I think we should keep it open for posterity because we get asked about it frequently enough. I can also use to link against PRODUCT tickets.

Comment by Peter Schmidt [ 07/Mar/17 ]

I believe this is now possible with the Advanced Query Bar in Compass 1.7+

If not please reopen
#keepitclean

Generated at Wed Feb 07 22:25:02 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.