> On 11 Dec 2024, at 11:39, John Naylor <johncnaylo...@gmail.com> wrote:
>
> On Mon, Dec 9, 2024 at 8:02 PM Andrey M. Borodin <x4...@yandex-team.ru> wrote:
>>
>> 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?
I do not have access to user data in most clusters... I remember only one
particular case: tags and folders applied to mail messages are represented by
int array. Mostly for GIN search. In that case vast majority of these arrays
are 0-10 elements, some hot-acceses fraction of 10-1000. Only robots (service
accounts) can have millions, and in their case latency have no impact at all.
But this particular case also does not trigger sorting much: arrays are stored
sorted and modifications are infrequent. In most cases sorting is invoked for
already sorted or almost sorted input.
So yeah, from practical point of view cosmetic reasons seems to be most
important :)
>> 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)
Seems like we cannot reuse same function...
So, let's do the function private for intarray and try to remove as much code
as possible?
Best regards, Andrey Borodin.
