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 converge at 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.nenciar...@2ndquadrant.it | www.2ndQuadrant.it
signature.asc
Description: OpenPGP digital signature
