Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
> On 12/09/2018 18:06, Tom Lane wrote:
>> No. In both code paths, the array slot at index first_te is being
>> physically dropped from the set of valid entries (by incrementing
>> first_te). In the first path, that slot holds the item we want to
>> remove logically from the set, so that incrementing first_te is
>> all we have to do: the remaining entries are still in the range
>> first_te..last_te, and they're still sorted. In the second code
>> path, the item that was in that slot is still wanted as part of
>> the set, so we copy it into the valid range (overwriting the item
>> in slot i, which is no longer wanted). Now the valid range is
>> probably not sorted, so we have to flag that a re-sort is needed.
> I see. Why not shift all items up to the i'th up by one place, instead
> of moving only the first one? That way the sortedness would be
> preserved. Otherwise we'd move the first one into the middle, then
> sorting would move it to the front again, etc.
Hmmm ... might be worth doing, but I'm not sure. The steady-state cycle
will probably be that after one task has been dispatched, we'll sleep
until some task finishes and then that will unblock some pending items,
resulting in new entries at the end of the list, forcing a sort anyway
before we next dispatch a task. So I was expecting that avoiding a sort
here wasn't really going to be worth expending much effort for. But my
intuition about that could be wrong. I'll run a test case with some
instrumentation added and see how often we could avoid sorts by
memmove'ing.
regards, tom lane
