Re: Greatest Common Divisor - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Greatest Common Divisor
Date
Msg-id 6387.1578157308@sss.pgh.pa.us
Whole thread Raw
In response to Re: Greatest Common Divisor  (Dean Rasheed <dean.a.rasheed@gmail.com>)
List pgsql-hackers
Dean Rasheed <dean.a.rasheed@gmail.com> writes:
> OTOH, for numeric inputs, this could easily end up needing many
> thousands of divisions and it's not hard to construct inputs that take
> minutes to compute, although this is admittedly with ridiculously
> large inputs (~10^130000), and AFAICS, the performance is OK with
> "normal" sized inputs. Should we put a limit on the size of the
> inputs?

No, but a CHECK_FOR_INTERRUPTS in the loop would be well-advised,
if there's not one already inside the called functions.

> There are apparently more efficient algorithms, but I think that
> should definitely be kept out of scope for this patch.

+1

            regards, tom lane



pgsql-hackers by date:

Previous
From: Justin Pryzby
Date:
Subject: allow disabling indexscans without disabling bitmapscans
Next
From: Tom Lane
Date:
Subject: Re: Errors when update a view with conditional-INSTEAD rules