Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

Selectivity estimators for <@(spoint, scircle) and spoint_dwithin(spoint, spoint, float8)#80

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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Merged
vitcpp merged 1 commit intopostgrespro:masterfromcybertec-postgresql:selectivity
Oct 20, 2023

Conversation

df7cb
Copy link
Contributor

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 likeselect * 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 returnsp1 <-> p2 <= radius. But other than
this two-operator expression, it has GIST index support so the optimizer
can rewrite it to eitherp1 <@ 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.

@esabol
Copy link
Contributor

This is an awesome contribution! Thank you!

@df7cb
Copy link
ContributorAuthor

df7cb commentedOct 7, 2023 via email

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.inelsepg_sphere--1.3.1--1.3.2.sql: pgs_circle_sel.sql.inendifcat ***@***.*** $^ > $@```--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.
esabol reacted with thumbs up emoji

Copy link
Contributor

@esabolesabol left a 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
float8within = PG_GETARG_FLOAT8(2);
float8dist = spoint_dist(p1, p2);

PG_RETURN_BOOL(dist <= within);
Copy link
Contributor

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.

esabol reacted with thumbs up emoji
Copy link
ContributorAuthor

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).

Copy link
Contributor

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.

Copy link
ContributorAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Implemented in89dc41d.

esabol reacted with thumbs up emoji
@esabol
Copy link
Contributor

In case anyone is interested in comparing selectivity estimators, similar efforts are in progress over in the q3c repo as well:

segasai/q3c#30
https://github.com/segasai/q3c/pull/35/files

df7cb, vitcpp, and Alena0704 reacted with thumbs up emoji

@df7cb
Copy link
ContributorAuthor

Rebased.

Copy link
Contributor

@vitcppvitcpp left a 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 estimatedto 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 appropriatedepending 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 optimizercan 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 encodethe join ordering in the query.On PostgreSQL 10/11, the spoint_dwithin function is created, but withoutthe 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.
@vitcppvitcpp merged commit4dfc663 intopostgrespro:masterOct 20, 2023
@vitcpp
Copy link
Contributor

@df7cb Thank you for the PR!

esabol and df7cb reacted with thumbs up emoji

@df7cb
Copy link
ContributorAuthor

@vitcpp@esabol@Alena0704 thanks for the reviews!

esabol reacted with thumbs up emoji

@df7cbdf7cb deleted the selectivity branchOctober 23, 2023 10:17
Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment
Reviewers

@vitcppvitcppvitcpp approved these changes

@esabolesabolesabol approved these changes

@Alena0704Alena0704Alena0704 approved these changes

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

4 participants
@df7cb@esabol@vitcpp@Alena0704

[8]ページ先頭

©2009-2025 Movatter.jp