maria-developers team mailing list archive
Mailing list archive
Re: custom storage backend rnd_next() implementation and caching questions
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?
Sent with Airmail
On 30 Jan 2015 at 19:05:34, Sergei Golubchik (serg@xxxxxxxxxxx) wrote:
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
> sql/field.cc:6876(Field_varstring::store(char const*, unsigned int, charset_info_st const*))[0x840032c]
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
A longer explanation is here: http://mariadb.atlassian.net/browse/MDEV-6381