Hi Sergei,
Sergei Golubchik wrote:
...
> Does it mean that partition fields will be in read_set even for SELECT's
> when there's no need to calculate partition function ?
Yes. I did not change this aspect of the implementation. They have been
added unconditionally.
> I'd expect read_set to be extended only if a write is expected (e.g. if
> write_set is not empty).
I am now testing the following:
DBUG_ENTER("ha_partition::rnd_init");
- include_partition_fields_in_used_fields();
-
- /*
- If write_set contains any of the fields used in partition and
- subpartition expression, we need to set all bits in read_set because
- the row may need to be inserted in a different [sub]partition. In
- other words update_row() can be converted into write_row(), which
- requires a complete record.
- */
- if (bitmap_is_overlapping(&m_part_info->full_part_field_set,
- table->write_set))
- bitmap_set_all(table->read_set);
+ if (!bitmap_is_clear_all(table->write_set))
+ {
+ /*
+ If write_set contains any of the fields used in partition and
+ subpartition expression, we need to set all bits in read_set because
+ the row may need to be inserted in a different [sub]partition. In
+ other words update_row() can be converted into write_row(), which
+ requires a complete record.
+ */
+ if (bitmap_is_overlapping(&m_part_info->full_part_field_set,
+ table->write_set))
+ bitmap_set_all(table->read_set);
+ else
+ {
+ /*
+ Some handlers only read fields as specified by the bitmap for the
+ read set. For partitioned handlers we always require that the
+ fields of the partition functions are read such that we can
+ calculate the partition id to place updated and deleted records.
+ */
+ bitmap_union(table->read_set, &m_part_info->full_part_field_set);
+ }
+ }
Regards
Ingo
--
Ingo Strüwing, Senior Software Developer
MySQL GmbH, Radlkoferstr. 2, D-81373 München
Geschäftsführer: Kaj Arnö - HRB München 162140
