Currently we do not support BLOB and Dynamic row format for HEAP table, which results in need for creating disk based temporary tables even for small result sets, if BLOBs are selected as well as possible excessive memory usage due to VARCHAR->CHAR extension. This is also limitation on user level table usage. The challange is to add these features, without performance hit, due to more compex memory allocation strategy. As most typical case for internal table usage, as well as for user level temporary tables is filling all table at once, we can optimize for this use case, having updates which change row length less optimal or even blocked on the initial stage Allocated to Pekka with limit of 5 days work. If it takes longer it will be moved to later release. There has been an interesting idea by a user: http://forums.mysql.com/read.php?92,130771,140237#msg-140237 Add a pointer to the fixed length record for every blob. Store the blob elsewhere. While records are stored bottom up in the tables memory pool, we could perhaps allocate blobs top down. The table is full when they meet in the middle. To reduce fragmentation, we could store the blobs in chunks of record size. Perhaps even link them in a chain so that fragments can be reused. OPTIMIZE could move lower fragments up into gaps so that more records can be added. The charm of the idea is that we won't need to implement "real" variable length records. This should make things much simpler.