On 11/12/15 19:18, Marco Nenciarini wrote:
> 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.
>
The full query is attached.
Regards,
Marco
--
Marco Nenciarini - 2ndQuadrant Italy
PostgreSQL Training, Services and Support
marco.nenciarini@2ndQuadrant.it | www.2ndQuadrant.it