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 th
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 --
Hi, Nikita!
On Dec 17, Nikita Malyavin wrote:
> It is used in innodb's implementation of handler::position, to copy the key
> from the record buffer, which is also used to be record[0]
Okay.
It seems that position() was always called with record[0] as an
argument.
But check_duplicate_long_entry
It is used in innodb's implementation of handler::position, to copy the key
from the record buffer, which is also used to be record[0]
On Tue, 17 Dec 2019 at 01:20, Sergei Golubchik wrote:
> Hi, Nikita!
>
> On Dec 06, Nikita Malyavin wrote:
> > Hi Sergei!
> >
> > I traced out the problem I faced
Hi, Nikita!
On Dec 06, Nikita Malyavin wrote:
> Hi Sergei!
>
> I traced out the problem I faced with refs comparison -- It's in
> key_copy implementation, which uses field->get_key_image, which in
> turn copied data to the buffer passed, but from `field->ptr`. The
> latter is important -- it mean
5 matches
Mail list logo
