[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/