On Fri, May 10, 2024 at 02:25:09PM -0500, Justin Tobler wrote:

On 24/05/08 01:04PM, Patrick Steinhardt wrote:

quoted

When seeking on a merged table, we perform the seek for each of the
subiterators. If the subiterator hasa the desired record we add it to

s/hasa/has/

Fixed.

quoted

the priority queue, otherwise we skip it and don't add it to the stack
of subiterators hosted by the merged table.

The consequence of this is that the index of the subiterator in the
merged table does not necessarily correspond to the index of it in the
merged iterator. Next to being potentially confusing, it also means that
we won't easily be able to re-seek the merged iterator because we have
no clear connection between both of the data structures.

Ah, I also found this a bit confusing. I think this is a good change.

quoted

Refactor the code so that the index stays the same in both structures.

Was there any advantage to not adding subiterators to the stack
originally? It looks like it adding them doesn't affect anything.

Not to the best of my knowledge, no.

Patrick