On Wed, 4 Dec 2019 at 05:04, Sergei Golubchik <s...@mariadb.org> wrote:
> > > > > two rows are the same, if their "positions" are equal, not if > > > > > their column values are equal. Also positions are much shorter > > > > > to compare. > > > > > > > > > > after ha_index_read_map or ha_index_next you do > > > > > > > > > > handler->position(record_buffer) > > > > > > > > > > and then you have a "position" stored in handler->ref, and it > > > > > has the length of handler->ref_length bytes. For MyISAM it's > > > > > usually the file offset, for InnoDB - PK value. > > > > > > > > > > For UPDATE you can, I suppose, call this->position(old_data) to > > > > > get the position. > > > > > > old_data could have been even not fetched, and in some cases handler > > is not cloned, so it can't work in general. > > In what cases? We're talking about UPDATE here, there's `this` handler > that has already read old_data, so `this->position()` is well defined. > > Hmm yes... I guess ha_update_row wouldn't even work correctly if old_data is not the last fetched row. I remember that was true for myisam at least -- ha_write_row was spoiling ref (when history row was inserted, or period row were split in FOR PORTION case), and that was worked around -- either by saving/restoring positions, or by having separate file with rowids > So both positions exist, can be read and compared. What's not general > here, that it doesn't work for INSERT? It doesn't have to, this is > special logic for UPDATE only. > Ok, I still think it is a little bit a hack but we can try and see if it'll work in long term. -- Yours truly, Nikita Malyavin
_______________________________________________ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
