maria-developers team mailing list archive

[Sergei Golubchik <serg@xxxxxxxxxxx>]

Hi, Nikita!

I agree.  In fact, I wrote the same in my review (should be finished in
a couple of hours).

I can think of one important case where in-TABLE vs in-handler makes a
difference - this is partitioning. All partitions share the same TABLE,
but every partition has its own handler. And in this case the "handler
for cascading index searches" has to be per partition too, so it cannot
be stored in the TABLE.

On Dec 17, Nikita Malyavin wrote:
> Yes, Sergei, you are right, it works fine!
> 
> Additionally, I see now that I implement something very similar to
> what Sachin does -- i.e., cloning handler.
> 
> I think that we can share one handler among all similar stuff, when we
> need to make cascade index searches. But some refactoring is required
> -- TABLE::clone_handler_for_update is not actually "for update" but
> rather for read, and I think it's better to store the handler in
> parent handler (as well as clone function), and to call it smth like
> `internal_handler` (I call it now check_overlaps_handler, and Sachin
> calls it update_handler).
> 
> Sergei, Sachin, agree?
> 
Regards,
Sergei
VP of MariaDB Server Engineering
and security@xxxxxxxxxxx