Hi, Alexey! On Feb 04, Alexey Botchkov wrote:

Hi, Sergei.

Below are my reply on your comments. I think it's better get these agreed before I produce the new patch.

...

...

+ if ((sav_inited= f->inited) == RND) + f->ha_rnd_end();

When can this happen? UPDATE statements do the rnd_init() in order to access through rnd_pos, and when they need to do the table scan.

So, UPDATE does rnd_init(), then rnd_pos(), then update_row(), and at that point you need to look up the key in all partitions, so you need index_read()? Could you, please, add a comment here to explain this sequence of events?

...

...

+int ha_partition::check_uniques_insert(uchar *buf, ... + {

can you use key_copy() here? Difficult to use here key_copy() as it is. Here i need to get the record from the arbitrary buffer, while key_copy() gets it from the table->record[0]. It seems weird that the key_copy() actually has the 'from_record argument, but only uses it to check the null bit.

May be, fix it? Meaning, adding 'offset' argument to Field::get_key_image(), I suppose.

...

...

@@ -283,6 +283,14 @@ class partition_info : public Sql_alloc .. + uint n_uniques_to_check; + uchar *unique_key_buf[2];

Is it safe? Isn't partition_info shared between many handlers so that every handler can only use it read-only? it's not quite clear to me. it seems that every TABLE has its own partition_info. But cloned handlers all share the same partition_info.

You're right, cloned handlers all share the same part_info. I didn't notice this. So i guess i should move the uniue_key_buf[2] to the class ha_partition. Do you know BTW if we ever use cloned handlers to write/update?

I don't know, sorry. Regards, Sergei Chief Architect MariaDB and security@mariadb.org