Thanks for taking some time for me,
> 1. You are using the prebuilt heap to allocate memory in
> this will result in a memory leak (of sorts). The heap
> will only be
> freed when MySQL
> closes the table handler.
I was afraid of this. Unfortunately the heap is coupled to 'lastread' which needs to be
remembered over multiple next() calls. I guess that's going to be a messy heap create/free
for each tuple copy.
> 2. You are reading the page numbers in separate mini-transactions (mtr) once
> btr_get_prefetch_pages() to collect the page numbers to read and
> a second
> mtr to
> do the actual read. The tree structure could
> potentially change between
> the invocations.
> Not sure if this causes issues.
I think the tradeoff for lower locktime compared to a few prefetch misses is acceptable.
> 3. The 6.0 release I believe had some MRR code, have you looked at that code?
Not yet, my MRR code is just the wrapper from handler.h, but i will take a look at 6.0
> 4. I couldn't figure out the purpose of key_val_buff2 in
It's used for the 'other' row_sel_convert_mysql_key_to_innobase. This construct was just
copy-pasted from records_in_range()
I have some more things to fix though, I noticed that I am currently ignoring the 'buffer'
argument on the index_read, etc functions and just always writing to table->record.
I'm afraid this could break in some cases (a grep of the sourcecode revealed some
Will post an update later today with fixes.