On Fri, May 10, 2024 at 02:25:09PM -0500, Justin Tobler wrote: > On 24/05/08 01:04PM, Patrick Steinhardt wrote: > > 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. > > 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. > > > > 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
Attachment:
signature.asc
Description: PGP signature
