Hi!
On Jun 22, Ingo Strüwing wrote:
> Sergei Golubchik wrote:
> > On Jun 22, Ingo Strüwing wrote:
> ...
> >> The importance of the question is made by the fact that we need to do
> >> the same in the partition handler when an update moves a record from
> >> one partition to another. ha_partitiom::update_row() calls
> >> handler::write_row() in this case and must provide a complete record.
> >
> > In this case you don't need to clone at all. As I wrote above "in
> > any case all the above can be skipped if the necessary bit is already
> > set". That is, partition handler needs the complete record, so it sets
> > all bits in read_set.
>
> It doesn't do it yet. Thus Bug#26827. Isn't it too inefficient to read
> all columns, just because two of a million records need to change the
> partition? In all other cases the reduced read_set is sufficient for the
> update. Wasn't it for efficiency that read_set is not always complete
> for update?
Yes, inefficient. Yes, for efficiency.
> If you think it's ok for the partition handler to always read complete
> records, I could copy Sergeys CSV change to partition. That would make a
> quick fix for Bug#26827.
Frankly speaking, I didn't think about partitioning problem. I only
wrote about "Bug#28158 - table->read_set is set incorrectly, causing
wrong error message". A bug in partitioning is independent from it.
I would agree that partition handler needs to read the complete row if a
partitioning column is in the write_set. That is, if a column, on which
the data are partitioned, is in write_set, you could set all bits in
read_set.
Regards / Mit vielen Grüssen,
Sergei
--
__ ___ ___ ____ __
/ |/ /_ __/ __/ __ \/ / Sergei Golubchik <serg@stripped>
/ /|_/ / // /\ \/ /_/ / /__ Principal Software Developer
/_/ /_/\_, /___/\___\_\___/ MySQL GmbH, Radlkoferstr. 2, D-81373 München
<___/ Geschäftsführer: Kaj Arnö - HRB
München 162140
