On Wed, 4 Dec 2019 at 01:00, Nikita Malyavin <nikitamalyavin@gmail.com> wrote:
On Tue, 3 Dec 2019 at 23:59, Sergei Golubchik <serg@mariadb.org> wrote:
But it can be done better. You search for the key with the same value and a period start <= than the period start of new row. And then you have to check two rows for overlaps. If you'll search for a key with the period start <= than the _period end_ of the new row, then you'll only need to check one row (may be one more, if updating).
It can't work just that way: to handle case when period start = _period end_ of the new row, you should write even more checks, and then move cursor left.
No, I don't see that. Can you show an example where you'd need even more checks?
Ok, suppose you have to rows in table with periods: (b, c), (c, d).
Now you insert (a, c). ha_index_read_map will look for period_start <= c, so it will return (c, d). These rows do not overlap, but we yet do not know if (b, c) is there. So we need to go to the previous row.
Now the algorithm looks same complex: read key, make some checks, got to the prev record.
I see. Because intervals are inclusive we probably have to search with < not <=. HA_READ_BEFORE_KEY
Yes, suddenly I didn't think about < (i.e., HA_READ_BEFORE_KEY), but that can work
Another case: suppose you have to rows in table with periods (a<b<c<d): (a, c), (c, d). Let us update (c,d) --> (b,d). I call it "move left". ha_index_read_map with period_start < d will return (c,d). Again check is_update, and call ha_index_prev()