Opened 11 years ago

Closed 6 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 mloskot, 11 years ago

Cc: mateusz@… added

comment:2 by pramsey, 10 years ago

Milestone: PostGIS 2.0.5PostGIS 2.0.6

comment:3 by pramsey, 9 years ago

Milestone: PostGIS 2.0.7PostGIS 2.0.8

comment:4 by pramsey, 7 years ago

See #1697 and change set for some insight into the issue in the ND space

comment:5 by pramsey, 7 years ago

Version: 2.0.x2.2.x

comment:6 by pramsey, 7 years ago

Milestone: PostGIS 2.0.8PostGIS 2.2.6

comment:7 by pramsey, 7 years ago

Milestone: PostGIS 2.2.6PostGIS 2.2.7

comment:8 by pramsey, 6 years ago

Resolution: wontfix
Status: newclosed

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 pramsey, 6 years ago

Resolution: wontfix
Status: closedreopened

comment:10 by pramsey, 6 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:11 by pramsey, 6 years ago

The problem showed up while working on #2256

comment:12 by pramsey, 6 years ago

Updated empty key to be BOX(nan nan, nan nan) at r16151, in support of estimated extent from index.

comment:13 by pramsey, 6 years ago

Resolution: fixed
Status: reopenedclosed
Note: See TracTickets for help on using tickets.