2

I am using Parse version "1.14.4" iOS 10.3.2 and swift 3. The query is slow whether local (he objects returned are pinned) or remote. Thanks

let placeObject = PFObject(className:"PlaceObject")
let point = PFGeoPoint(latitude:self.PointGlobal.latitude, longitude:self.PointGlobal.longitude)
placeObject["location"] = point
let query = PFQuery(className:"CLocationObject")
// Interested in locations near user.
query.whereKey("location", nearGeoPoint:point)
// Limit what could be a lot of points.
query.limit = 200
let localQuery = (query.copy() as! PFQuery).fromLocalDatastore()

localQuery.findObjectsInBackground{
  (objects: [PFObject]?, error: Error?) -> Void in

self.dataReturnedLocally = true

.....

if self.dataReturnedLocally{
print("local query with no error there was data already")
}

  else {
  print("getting data remotely")
  query.findObjectsInBackground{
    (objects: [PFObject]?, error: Error?) -> Void in
    if error == nil {

      if let objects = objects  {
Shaik Riyaz
  • 11,204
  • 7
  • 53
  • 70
user2867432
  • 382
  • 4
  • 14

2 Answers2

1

geo based queries are the slowest types of queries with MongoDB, unfortunately. Also, there are not automatically indexes based on location, making these extra slow, especially for large collections. So, your only real solution is to add indexes to your database to index the location, optimized for the location queries you'll need to make. Though keep in mind too many of these affects write speed.

Depending on your use case, it may be better to use withinMiles instead of nearGeoPoint. This will return fewer results, but will not take as long to run, either.

Jake T.
  • 4,308
  • 2
  • 20
  • 48
  • Thanks Jake, but the local queries are slow as well. That should not be related to MongoDB in this case. – user2867432 Jul 13 '17 at 20:36
  • Geo based queries are gonna be the slowest types of queries locally, and unfortunately I don't think you're able to get into the nitty gritty with local data store. I'm not aware of any indexing you can do with that. So, your best bet there is to again, change it to withinMiles instead of whereNear. Not much else to do. – Jake T. Jul 13 '17 at 22:08
  • Thanks Jake but in my case it won't make a difference since it would return the same number of data points. Are you aware of a technique where we could query not previously returned data in Parse? – user2867432 Jul 13 '17 at 22:20
1

All queries in the LDS are slow at the moment as they are not indexed. The LDS stored an objectId / JSON representation of the data and all filtering is done in memory.

flovilmart
  • 1,759
  • 1
  • 11
  • 18
  • When you say all, you mean all Parse LDS? – user2867432 Jul 14 '17 at 21:43
  • I mean every time you make a query against the LDS, the query filtering is done in memory – flovilmart Jul 15 '17 at 16:00
  • Ok. So overall the queries are just slow whether using LDS or remote? Would you recommend successive smaller queries ? If so how would you implement something like this : query 1 then query 2 would be results not in query 1? Thanks – user2867432 Jul 15 '17 at 16:08
  • If your queries are slow in remote, you should probably look into your indexes, the mongodb logs will print any slow queries above a certain threshold https://docs.mongodb.com/manual/tutorial/manage-the-database-profiler/ For the LDS' I recommend you use different pins so the local data for a certain query is isolated until we find a good solution :) – flovilmart Jul 15 '17 at 16:17
  • Thanks, will do on the DB side. On the LDS side, what do you mean by different pins ? – user2867432 Jul 15 '17 at 16:47