[postgis-devel] EMPTY and Indexes

[Paul Ramsey]

I think from an index pov we can say that EMPTY && EMPTY = true and EMPTY = EMPTY is true in all cases. Then the secondary filter can handle logic around type differences, etc. Then for searching we just make sure that they are always over-right. So, yeah, all empties end up with one effective value, indexwise.

For invalid boxes, maybe we drop them all into another quadrant? underleft? They are harder to search for, indexwise, I'm trying to imagine the use case. That determines what kind of key semantics we'd want for them? Are all invalid boxes equal? If not, how would you ever find them? More difficult, how about overlaps, etc, conditions on invalid boxes? Do we even contemplate that or just drop them into an invalid bucket and allow only equality to find them.

P


> On Mar 23, 2020, at 10:04 AM, rmrodriguez at carto.com wrote:
> 
> It looks like an interesting idea for future releases (so we don't
> break existing indexes).
> 
> Have you given any thought about how to deal with the different types
> of EMPTY geometries? That is, $VALID_GEOMETRIES <= POINT EMPTY <=
> LINESTRING EMPTY <= POLYGON EMPTY and so on, or just group all empty
> geometries together in a single value.
> And also, how would we deal with invalid geometries (that contain Nan
> values, so they have NaN bboxes)?
> 
> Ideally I'd try to fix both issues in the same strike.
> 
> 
> 
> -- 
> Raúl Marín Rodríguez
> carto.com
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/postgis-devel