[
https://issues.apache.org/jira/browse/LUCENE-7212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15239819#comment-15239819
]
Robert Muir commented on LUCENE-7212:
-------------------------------------
I ran some rough benchmarks. its tough because the filter we use is itself
costly :) Also i use an ancient jvm and hardware and my numbers are in general
very different from what mike reports.
{noformat}
2D distance with 100% filter: 16.0 QPS
2D distance with 10% filter: 24.1 QPS
2D distance with 1% filter: 42.7 QPS
2D distance with 0.1% filter: 51.1 QPS
2D distance with 0.0001% filter: 55.7 QPS
3D distance with 100% filter: 21.7 QPS
3D distance with 10% filter: 31.9 QPS
3D distance with 1% filter: 36.6 QPS
3D distance with 0.1% filter: 38.2 QPS
3D distance with 0.0001% filter: 42.3 QPS
{noformat}
For distance: I'm not sure geo3d needs two-phase support: i don't think its
per-doc checks are so expensive? For 2D we should reinvestigate it too: maybe
it has outgrown the need for a "two-phase crutch". Maybe its really overkill
after LUCENE-7147 since there are no longer tons of per-doc boundary cases
being evaluated. And there is truly some cost for "throwing away" the data
points that BKD sends us and then suffering docvalues reads later to fetch them
from a different storage.
For polygons: its hard for me to see. Both 2D and 3D get really slow as polygon
complexity increases. For 2D the per-doc check is O(#vertices). But 2D also has
an expensive up-front cost (grid construction) that you can see bounds the
performance of these complex queries regardless of how any hits they have. For
3D i'm not sure where the heavy cost lies with these. It might not be related
to per-doc checks at all.
Polygon (n=500)
{noformat}
2D poly with 100% filter: 7.2 QPS
2D poly with 10% filter: 16.1 QPS
2D poly with 1% filter: 25.9 QPS
2D poly with 0.1% filter: 28.6 QPS
2D poly with 0.0001% filter: 29.8 QPS
3D poly with 100% filter: 1.9 QPS
...
3D poly with 0.0001% filter: 2.0 QPS
{noformat}
This is my commit:
https://github.com/mikemccand/luceneutil/commit/4e22c6abeedb00bf6de66d4c3fbefbd95cb26b98
Anyway take the numbers with a grain of salt. It might be worthwhile to
investigate what is happening with polygons with geo3d though, i think
something is not right there. Lots more experiments needed...
> Add Geo3DPoint equivalents of LatLonPointDistanceComparator and
> LatLonPointSortField
> ------------------------------------------------------------------------------------
>
> Key: LUCENE-7212
> URL: https://issues.apache.org/jira/browse/LUCENE-7212
> Project: Lucene - Core
> Issue Type: Improvement
> Affects Versions: master
> Reporter: Karl Wright
> Assignee: Karl Wright
>
> Geo3D has a number of distance measurements and a generic way of computing
> interior distance. It would be great to take advantage of that for queries
> that return results ordered by interior distance.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
