Thanks Keith. I tried your suggestion, and yes, it is much better, much more performant. It is as fast as doing a simple `geopoly` query in the examples in my OP. Here it is
```
SQLite version 3.32.3 2020-06-18 14:00:33
Enter ".help" for usage hints.
sqlite> .eqp on
sqlite> .timer on
sqlite> SELECT Count(*) FROM treatments WHERE treatmentId IN (SELECT treatmentid FROM vtreatments WHERE vtreatments MATCH 'meshram' INTERSECT SELECT treatmentid FROM vlocations WHERE geopoly_within(_shape, '[[3.9291576420597614,25.653199999999963],[3.9205272039128367,25.57418480393311],[3.8949675523700438,25.498156902884112],[3.853460930506155,25.428046553409356],[3.797602414522217,25.366560752342917],[3.7295386158616766,25.316077273341982],[3.6518851881364403,25.278551030320266],[3.567626309025444,25.25543670701288],[3.4800000000000004,25.24763096138966],[3.3923736909745563,25.25543670701288],[3.30811481186356,25.278551030320266],[3.230461384138324,25.316077273341982],[3.1623975854777835,25.366560752342917],[3.106539069493846,25.428046553409356],[3.0650324476299566,25.498156902884112],[3.0394727960871637,25.57418480393311],[3.03084235794024,25.653199999999963],[3.0394727960871637,25.73216289757996],[3.0650324476299566,25.808041865571695],[3.106539069493846,25.877929322171752],[3.162397585477784,25.93915220501075],[3.2304613841383247,25.989372767781138],[3.3081148118635615,26.026676122749052],[3.3923736909745577,26.049641517820053],[3.4800000000000013,26.05739496695326],[3.5676263090254454,26.049641517820053],[3.6518851881364416,26.026676122749052],[3.7295386158616783,25.989372767781138],[3.7976024145222183,25.93915220501075],[3.853460930506156,25.877929322171752],[3.894967552370044,25.808041865571695],[3.920527203912837,25.73216289757995],[3.9291576420597614,25.653199999999963]]') != 0);
QUERY PLAN
|--SEARCH TABLE treatments USING COVERING INDEX sqlite_autoindex_treatments_1 (treatmentId=?)
`--LIST SUBQUERY 2
`--COMPOUND QUERY
|--LEFT-MOST SUBQUERY
| `--SCAN TABLE vtreatments VIRTUAL TABLE INDEX 0:m
`--INTERSECT USING TEMP B-TREE
`--SCAN TABLE vlocations VIRTUAL TABLE INDEX 4:fullscan
1
Run Time: real 1.813 user 1.594897 sys 0.087140
```
It also give a better result because of the tighter selection (I get a count = 1 as opposed to a count = 2 for my bbox query where I search for `latitude BETWEEN min_lat AND max_lat AND longitude BETWEEN min_lng AND max_lng`. But the bbox query is much faster. This `INTERSECT` approach is also much more complicated for me to construct programmatically. So, I think I will stick to my bbox methodology. But how on earth would I have discovered this if you hadn't been around? I ask this seriously in a quest to understand what is going on?
And why are RTree queries (geopoly uses RTree in the background) so slow as compared to, say, FTS5 which is like magic.