[Replying to an old thread...] > A customer of ours hit some very slow code while running the > @>(polygon, polygon) operator with some big polygons. I'm not familiar > with this stuff but I think the problem is that the algorithm converges > too slowly to a solution and also has some pretty expensive calls > somewhere. (Perhaps there is also a problem that the algorithm *never* > converges for some inputs ...)
I believe there is a simple flaw on the algorithm that causes it loop endlessly. It should stop looking at the other segments of the polygon after finding the touching one. The attached patch fixes the issue for the query posted to this thread. I suggest backpacking the fix. There are many code quality issues and bugs like this still unresolved on geo_ops.c. I am trying to improve it. Any help appreciated: https://commitfest.postgresql.org/16/1160/
0001-polygon-contains-lseg-loop-fix-v00.patch
Description: Binary data
