-
Notifications
You must be signed in to change notification settings - Fork 14
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Selectivity estimators for <@(spoint, scircle) and spoint_dwithin(spoint, spoint, float8) #80
Conversation
This is an awesome contribution! Thank you! |
Am 6. Oktober 2023 21:41:54 MESZ schrieb Ed Sabol ***@***.***>:
@esabol commented on this pull request.
> @@ -241,8 +248,11 @@ pg_sphere--1.2.3--1.3.0.sql: pgs_brin.sql.in
pg_sphere--1.3.0--1.3.1.sql:
cat ***@***.*** > $@
-pg_sphere--1.3.1--1.3.2.sql:
- cat ***@***.*** > $@
+ifeq ($(has_support_functions),y)
+pg_sphere--1.3.1--1.3.2.sql: pgs_gist_support.sql.in
+endif
+pg_sphere--1.3.1--1.3.2.sql: pgs_circle_sel.sql.in
+ cat ***@***.*** $^ > $@
I'm not sure, but I wonder if lines 251-255 should be the following instead?
```
ifeq ($(has_support_functions),y)
pg_sphere--1.3.1--1.3.2.sql: pgs_gist_support.sql.in pgs_circle_sel.sql.in
else
pg_sphere--1.3.1--1.3.2.sql: pgs_circle_sel.sql.in
endif
cat ***@***.*** $^ > $@
```
--
Reply to this email directly or view it on GitHub:
#80 (review)
You are receiving this because you authored the thread.
Message ID: ***@***.***>
It does works that way, $^ collects all dependencies.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually, could you make a couple minor tweaks to the documentation changes? Thanks!
src/point.c
Outdated
float8 within = PG_GETARG_FLOAT8(2); | ||
float8 dist = spoint_dist(p1, p2); | ||
|
||
PG_RETURN_BOOL(dist <= within); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess, FPle should be used instead of direct comparison. pgSphere calculations are executed with EPSILON = 1E-9. When we compare two distances, all the numbers less than 1E-9 should be treated as zeroes, I think. There is the example: spoint_in_circle() function, where FPle is used. I would also propose to add some tests for this function, if it can be done.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ack, will change that (likely later, not now).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure, thank you! No hurry.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Implemented in 89dc41d.
In case anyone is interested in comparing selectivity estimators, similar efforts are in progress over in the q3c repo as well: |
Rebased. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just one trivial change. Thank you!
This implements restriction selectivity estimation for the <@ @> !<@ !@> family of operators on spoint and scircle. The selectivity is estimated to be (area of sphere circle) / (4 pi). Queries like `select * from sky where sky.star <@ scircle(const, radius)` will be able to properly estimate if using an index is appropriate depending on the size of radius. Secondly, a function spoint_dwithin(p1 spoint, p2 spoint, radius float8) is added that effectively returns `p1 <-> p2 <= radius`. But other than this two-operator expression, it has GIST index support so the optimizer can rewrite it to either `p1 <@ scircle(p2, radius)` or `p2 <@ scircle(p1, radius)`, i.e. it is symmetric in the first two arguments. This allows efficient matching queries without the user having to encode the join ordering in the query. On PostgreSQL 10/11, the spoint_dwithin function is created, but without the GIST support since that only appeared in PG12. The file expected/selectivity_1.out is used on PG10/11; it has <@ flipped around to @> in some plans.
@df7cb Thank you for the PR! |
@vitcpp @esabol @Alena0704 thanks for the reviews! |
This implements restriction selectivity estimation for the <@ @> !<@ !@>
family of operators on spoint and scircle. The selectivity is estimated
to be (area of sphere circle) / (4 pi).
Queries like
select * from sky where sky.star <@ scircle(const, radius)
will be able to properly estimate if using an index is appropriate
depending on the size of radius.
Secondly, a function spoint_dwithin(p1 spoint, p2 spoint, radius float8)
is added that effectively returns
p1 <-> p2 <= radius
. But other thanthis two-operator expression, it has GIST index support so the optimizer
can rewrite it to either
p1 <@ scircle(p2, radius)
orp2 <@ scircle(p1, radius)
, i.e. it is symmetric in the first two arguments.This allows efficient matching queries without the user having to encode
the join ordering in the query.
On PostgreSQL 10/11, the spoint_dwithin function is created, but without
the GIST support since that only appeared in PG12.
The file expected/selectivity_1.out is used on PG10/11; it has <@
flipped around to @> in some plans.