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 ...)

While I'm not familiar with the code itself, and can't post the exact
slow query just yet, I have noticed that it is missing a
CHECK_FOR_INTERRUPTS() call to enable cancelling the slow query.  I'd
backpatch this all the way back.  (The exact issue they hit is mutual
recursion between touched_lseg_between_poly and lseg_between_poly.
Since the latter also recurses on itself, the best way forward seem to
add a check for interrupts in the loop there.)

I will follow up on the actual slowness later, as warranted.

Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
diff --git a/src/backend/utils/adt/geo_ops.c b/src/backend/utils/adt/geo_ops.c
index 6ef420d..77871b1 100644
--- a/src/backend/utils/adt/geo_ops.c
+++ b/src/backend/utils/adt/geo_ops.c
@@ -20,6 +20,7 @@
 #include <ctype.h>
 #include "libpq/pqformat.h"
+#include "miscadmin.h"
 #include "utils/builtins.h"
 #include "utils/geo_decls.h"
@@ -3894,6 +3895,8 @@ lseg_inside_poly(Point *a, Point *b, POLYGON *poly, int start)
 		Point	   *interpt;
 		s.p[1] = poly->p[i];
 		if (on_ps_internal(t.p, &s))
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to