Opened 11 years ago
Closed 7 years ago
#2487 closed defect (fixed)
Support invalid keys in GiST index
Reported by: | pramsey | Owned by: | pramsey |
---|---|---|---|
Priority: | high | Milestone: | PostGIS 2.2.7 |
Component: | postgis | Version: | 2.2.x |
Keywords: | Cc: | mateusz@… |
Description
For various input geometries (ones with NaN coordinates, EMPTY ones) there is no reasonable box2df that can be created to represent it within the index. We need to return a key, or an error, and we can't error particularly on valid things like EMPTY. So we need a key which means "just ignore me". Probably (NaN, Nan, Nan, Nan). Or, really, any box2df with xmin==NaN.
Then 2d ops and 3d ops need to be fixed up to understand it. And probably also Inf geometries need to be either supported (in all their Inf glory) or considered invalid as well.
This is legitimately a bug, though probably an under-exercised one, since people don't use invalid/empty geometries very much. It should be fixed all the way back into the 2.0 branch.
Change History (13)
comment:1 by , 11 years ago
Cc: | added |
---|
comment:2 by , 11 years ago
Milestone: | PostGIS 2.0.5 → PostGIS 2.0.6 |
---|
comment:3 by , 9 years ago
Milestone: | PostGIS 2.0.7 → PostGIS 2.0.8 |
---|
comment:4 by , 7 years ago
comment:5 by , 7 years ago
Version: | 2.0.x → 2.2.x |
---|
comment:6 by , 7 years ago
Milestone: | PostGIS 2.0.8 → PostGIS 2.2.6 |
---|
comment:7 by , 7 years ago
Milestone: | PostGIS 2.2.6 → PostGIS 2.2.7 |
---|
comment:8 by , 7 years ago
Resolution: | → wontfix |
---|---|
Status: | new → closed |
I'm declaring defeat on this ticket… without a facility at the GIST API that exposes how GIST already handles NULL values (somewhere out-of-line from the other entries, I guess) we cannot create a good key for invalid (empty) inputs, that are searchable, since the whole space we have available to us (the 2d plane) is monopolized by valid keys. We could pick an arbitrary place on the plane (our own "null island" for empties) and say "that's where we put them!" but such a hack would (a) pollute the space for things that are actually there and (b) would cause the root bounds to immediately be really huge, every time.
The downside, which doesn't seem to have caused anyone to complain, ever, is lack of indexed searches for empty geometry (also, geography). Finding them requires a full table scan using the '=' operator.
comment:9 by , 7 years ago
Resolution: | wontfix |
---|---|
Status: | closed → reopened |
comment:10 by , 7 years ago
I found a new reason to care about this: the nonsense values we insert when given an EMPTY end up creating very odd bboxes in the index when they arrive. Sometimes very small, sometimes very large. Having properly ignored NaN boxes would probably be preferable.
comment:12 by , 7 years ago
Updated empty key to be BOX(nan nan, nan nan) at r16151, in support of estimated extent from index.
comment:13 by , 7 years ago
Resolution: | → fixed |
---|---|
Status: | reopened → closed |
See #1697 and change set for some insight into the issue in the ND space