maria-developers team mailing list archive

[Sergey Petrunya <psergey@xxxxxxxxxxxx>]

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