← Back to team overview

maria-developers team mailing list archive

Re: custom storage backend rnd_next() implementation and caching questions

 

Hi Sergei,

 I am bringing up this topic again with a performance related question.

 Since the plugin is returning blob fields which can be large, for performance considerations we’ve chosen to use mmap to obtain the blob values. However it seems that the Field_blob::store(…) is using a malloc/memcopy to store the field value. In my understanding this is not required for the blob fields (data is represented as a ptr + size). Is there a method where i could bypass the copying?

 If i can bypass the copying of course i need to keep the mmap active until mysql has no need for the data. Is it right that rnd_end()  is the earliest point where i can release the mmap?

Thanks
 Andras

-- 
Andras Szabo
Sent with Airmail

On 30 Jan 2015 at 19:05:34, Sergei Golubchik (serg@xxxxxxxxxxx) wrote:

Hi, Andras!  

On Jan 30, Andras Szabo wrote:  
> Hi Sergei,  
>  
>  Thanks for the quick reply.  
>  
> 1. I have tried your suggestion (which is a cool simplification to my bit-messing… ;). Unfortunately the code is crashing now:  
>  
> mariadb’s crash report shows the following stack trace:  
>  
> stack_bottom = 0x9e5de314 thread_stack 0x30000  
> mysys/stacktrace.c:246(my_print_stacktrace)[0x89912c5]  
> sql/signal_handler.cc:153(handle_fatal_signal)[0x841593a]  
> [0xb76f5c58]  
> [0xb76f5c7c]  
> /lib/i386-linux-gnu/libc.so.6(gsignal+0x47)[0xb70e6607]  
> /lib/i386-linux-gnu/libc.so.6(abort+0x143)[0xb70e7d83]  
> /lib/i386-linux-gnu/libc.so.6(+0x27757)[0xb70df757]  
> /lib/i386-linux-gnu/libc.so.6(+0x27807)[0xb70df807]  
> sql/field.cc:6876(Field_varstring::store(char const*, unsigned int, charset_info_st const*))[0x840032c]  
> /usr/local/mysql/lib/plugin/ha_fsview.so(_ZN9ha_fsview8rnd_nextEPh+0xec)[0xb70adb00]  

You didn't tell why it's failing - it was in the log before the stack  
trace. I suspect it was signal 6 - abort (jugding from abort in the  
stack trace). Then it must be that ASSERT_COLUMN_MARKED_FOR_WRITE_OR_COMPUTED,  
and I suppose you're using debug build of the server.  

A fix would be to start your method with  

my_bitmap_map *old_map = dbug_tmp_use_all_columns(table, table->write_set);  

and to finish it with  

dbug_tmp_restore_column_map(table->write_set, old_map);  

A longer explanation is here: http://mariadb.atlassian.net/browse/MDEV-6381  

Regards,  
Sergei  

Follow ups

References