Hello Igor, It has come to my attention that sql_join_cache.cc does not have as many update_virtual_fields() calls as I think it ought to have. My reasoning was as follows: AFAIU when one has read a record from a table, they must call update_virtual_fields() before they try to evaluate the attached table condition (because the condition may refer to virtual fields). Now if one opens sql_join_cache.cc and looks at these three functions: JOIN_CACHE_BKA::join_matching_records(bool skip_last) { ... while (!(error= file->multi_range_read_next((char **) &rec_ptr))) { ... rc= generate_full_extensions(rec_ptr); ... } ... } JOIN_CACHE::generate_full_extensions(uchar *rec_ptr) { ... if (check_match(rec_ptr)) { ... } JOIN_CACHE::check_match(uchar *rec_ptr) { /* Check whether pushdown conditions are satisfied */ if (join_tab->select && join_tab->select->skip_record()) return FALSE; ... } one can see a call path where we read a table record with multi_range_read_next and then proceed to evaluating the attached condition with skip_record() without calling update_virtual_fields(). Is there a problem. Another thing I can't understand about update_virtual_fields() is the asymmetry between rr_XXX() functions. Why do rr_quick() and rr_sequential() call update_virtual_fields() while rr_index_first() and rr_from_pointers() don't? If that is intentional, I think it deserves to be documented. BR Sergey -- Sergey Petrunia, Software Developer Monty Program AB, http://askmonty.org Blog: http://s.petrunia.net/blog