Re: Sort functions with specialized comparators

On Mon, Dec 9, 2024 at 8:02 PM Andrey M. Borodin <x4mmm(at)yandex-team(dot)ru> wrote:
>
> > On 6 Dec 2024, at 08:49, John Naylor <johncnaylorls(at)gmail(dot)com> wrote:

> > That's a good thing to raise right now -- intarray currently doesn't
> > have one, and we haven't gotten complaints from people trying to sort
> > large arrays and cancel the query. This extension is not commonly
> > used, so that's not surprising. It could be that large arrays are even
> > less common, or no one bothered to report it. What's the largest size
> > that your customers use?
> >
> > If we do need a check for interrupts, then this whole thing must
> > remain private to intarray. From reading e64cdab0030 , it's not safe
> > to interrupt in general.
>
> I think commit message states that it's better to opt-in for interruptible sort. So I do not think making sort interruptible is a blocker for making global specialized sorting routines.

There is a difference, though -- that commit had a number of uses for
it immediately. In my view, there is no reason to have a global
interruptible sort that's only used by one contrib module. YAGNI

Also, I was hoping get an answer for how this would actually affect
intarray use you've seen in the wild. If the answer is "I don't know
of any one who uses this either", then I'm actually starting to wonder
if the speed matters at all. Maybe all uses are for a few hundred or
thousand integers, in which case the sort time is trivial anyway?

> We could use global function for oid lists which may be arbitrary large.

BTW, oids are unsigned. (See the 0002 patch from Thomas M. I linked to earlier)

--
John Naylor
Amazon Web Services