> > > > 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()