Hi,
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;
+ CHECK_FOR_INTERRUPTS();
+
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:
http://www.postgresql.org/mailpref/pgsql-hackers
