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/ > 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. -Justin
