On 11/12/15 18:48, Alvaro Herrera wrote:
> 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.
>
I would add that it was not simply a slow computation, but more probably they hit a case where the algorithm doesn't
convergeat all.
I've killed it manually by calling ProcessInterrupts() through gdb after 7 days and half of CPU time (100% of one CPU).
The server CPU is an Intel(R) Xeon(R) CPU E5-2660 v2 @ 2.20GHz.
The query doesn't involve any table and is a simple call of @>(polygon, polygon) operator.
SELECT polygon 'poligon literal with 522 points' @> polygon 'poligon box'
I'm checking if we can share the full query.
Regards,
Marco
--
Marco Nenciarini - 2ndQuadrant Italy
PostgreSQL Training, Services and Support
marco.nenciarini@2ndQuadrant.it | www.2ndQuadrant.it