List:Internals« Previous MessageNext Message »
From:Sergei Golubchik Date:July 16 2009 8:13am
Subject:Re: GSoC Week 10 - I_S/P_S storage engine
View as plain text  
Hi, scut_tang!

On Jul 16, scut_tang wrote:
> Hi, Sergei
> 
> >I want to see your changes, especially when you have problems.
> >Sending patches around is not very convenient - I've created a project
> >on launchpad, and added you there in the "maintainer" team, I suppose
> >you should be able to push here:
> >
> >   lp:~sergii/mysql-infoschema/trunk
> >
> >As you could not finish the push last time, I suggest not to try pushing
> >your tree there, but instead branch that url above, apply your changes
> >to the new tree as a patch, commit, and push.
> I am very sorry. I forgot to commit change before generated the diff
> file, so the diff file I send you was not right.
> Yesterday my lab power cut all the whole day, so I see your mail just now.
> I check the branch you created in luanchpad.net, but I find:
> 
> lp:~sergii/mysql-infoschema/trunk 
> Project:INFORMATION_SCHEMA GSoC 2009 Project
> Status:Development
> Get this branch:bzr branch lp:~sergii/mysql-infoschema/trunk
> Update this branch: You cannot upload to this branch. Only Sergei can upload to this
> branch. 
> Branch format:Branch format 6
> Repository format:Packs containing knits without subtree support
> Only you can upload to this branch? I tried bzr push
> lp:~sergii/mysql-infoschema/trunk, but it failed.

Hm, try this one:

  bzr push lp:~mysql-infoschema-2009/mysql-infoschema/trunk
 
> >No, instead of coming up with new names think of what operations your
> >index supports. Does it support ranges like a btree   "all file names
> >between abc and adef" - no, it cannot easily do that.
> >
> >In that sense it's closer to HASH.
> >
> So it is just closer to HASH, not exact HASH?

It can do more than HASH but less than BTREE. So, let's pretend it's a
HASH. Later, if we'll have time, we could extend it to do everything
BTREE can.
  
> >> 4. I don't know clearly about table->record[0-2]. Is
> >> table->record[0] connected with table->filed[]'s data 
> >
> >Correct.
> >
> Could you talk more about table->record[0], table->record[1],
> table->record[2]?

eh, what do you want to know ?

record[0] is where data are read to in handler read methods (like
index_read, index_next, rnd_pos, rnd_next, etc) and where data are
written from in handler write methods (write_row, update_row).
table->field[...].ptr points inside record[0], and val_xxx and store_xxx
methods of table->field[...] update record[0].

record[1] is used in UPDATE, for example, to store the old version of
the row data.

record[2] is filled with default values for all columns.

Regards / Mit vielen Grüßen,
Sergei

-- 
   __  ___     ___ ____  __
  /  |/  /_ __/ __/ __ \/ /   Sergei Golubchik <serg@stripped>
 / /|_/ / // /\ \/ /_/ / /__  Principal Software Engineer/Server Architect
/_/  /_/\_, /___/\___\_\___/  Sun Microsystems GmbH, HRB München 161028
       <___/                  Sonnenallee 1, 85551 Kirchheim-Heimstetten
Geschäftsführer: Thomas Schroeder, Wolfgang Engels, Wolf Frenkel
Vorsitzender des Aufsichtsrates: Martin Häring
Thread
OS/2 3.23.32: merge test failingYuri Dario27 Jan
  • Re: GSoC Week 10 - I_S/P_S storage engineSergei Golubchik18 Jul
  • Re: GSoC Week 10 - I_S/P_S storage engineSergei Golubchik18 Jul
Re: OS/2 3.23.32: merge test failingYuri Dario27 Jan