2đź‘Ť
Yes, I’d expect it to be slow since the geometry that you linked to is massive:
[[ MULTIPOLYGON - 346 elements, 36054 pts ]]
A GiST index won’t help either, since the CPU burning away to determine if the point is within this specific detailed multipolygon, rather then determining if it is within a bounding box (bbox) of thousands of rows of data. Note, here is the geometry and a bbox that overlaps a few continents:
Since the bbox warps over the date-line with +ve longitudes, it covers Europe. This means if you are querying a point in Europe, it will intersect the bbox for the United States, and PostGIS may need to check this large geometry to see if it is touches the polygon. See R-Tree to get an understanding of how the GiST index works, and why smaller boxes with fewer overlaps query fastest.
The best solution is to use smaller geometries, which inherently have fewer elements/points and will normally have smaller bboxes to help the GiST index. The “states” dataset you mentioned is more ideal, since they have limited geographic extents and probably fewer vertices (helps detailed spatial relation query). Besides Natural Earth, a really good dataset for determining administrative boundaries world wide is: http://www.gadm.org
Both these options will move the boundaries and change what “touches” means, since the boundaries are different and this make a huge difference for “touches”. Note that there are several other operators that are more common and mean different things, such as “intersects”, “contains”, and “within”; see https://en.wikipedia.org/wiki/DE-9IM