On Mon, Dec 9, 2024 at 8:02 PM Andrey M. Borodin <x4...@yandex-team.ru> wrote: > > > On 6 Dec 2024, at 08:49, John Naylor <johncnaylo...@gmail.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
