Re: [HACKERS] Uninterruptible slow geo_ops.c

From: Emre Hasegeli <emre(at)hasegeli(dot)com>
To: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [HACKERS] Uninterruptible slow geo_ops.c
Date: 2017-12-10 14:47:46
Message-ID: CAE2gYzw8BR4COVxmEhhVUY2utiAJL7Ep3TW8on=EUyQXU=YRig@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

[Replying to an old thread...]

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

I believe there is a simple flaw on the algorithm that causes it loop
endlessly. It should stop looking at the other segments of the
polygon after finding the touching one. The attached patch fixes the
issue for the query posted to this thread. I suggest backpacking the
fix.

There are many code quality issues and bugs like this still unresolved
on geo_ops.c. I am trying to improve it. Any help appreciated:

https://commitfest.postgresql.org/16/1160/

Attachment Content-Type Size
0001-polygon-contains-lseg-loop-fix-v00.patch application/octet-stream 28.0 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2017-12-10 15:42:24 Re: Rethinking MemoryContext creation
Previous Message Christian Ullrich 2017-12-10 12:36:13 RE: pl/perl extension fails on Windows