List:Summer of Code« Previous MessageNext Message »
From:Sergei Golubchik Date:July 27 2009 4:16pm
Subject:Re: GSoC Week 12 - I_S/P_S storage engine
View as plain text  
Hi, scut_tang!

On Jul 27, scut_tang wrote:
> 
> KEY ACCOMPLISHMENTS LAST WEEK
> ==============================
> Added tables GLOBAL_STATUS, GLOBAL_VARIABLES, SESSION_STATUS,
> SESSION_VARIABLES, VARIABLES and STATUS. Table STATUS will crash, but
> others work well. I will find the bug these day.

ok
 
> KEY CONCERNS
> ============
> 1. I have added lots of functions in sql_show.cc and sql_acl.cc, like
> fill_status_for_i_s, fill_variables_for_i_s, show_var_array_for_i_s
> and etc. I want to exact all them into I_S storage engine files,
> instead of MySQL server files. But the problems are variables and
> class (struct)'s definition, like some locks. Any advices?

Perhaps.
If you explain what the problem is, I could come up with an advice.

> 2. "SHOW TABLES FROM INFORMATION_SCHEMA" shows 30 tables, but
> schema_tables array contains 37 tables, where some tables are hidden.
> What is the purpose of hidding tables? For privileges?

No, for SHOW commands. E.g. SHOW VARIABLES is internally rewritten into
a select from an appropriate I_S table. So, these extra "hidden" I_S
tables are needed to support old legacy SHOW commands (backward
compatibility!).

> 3. Today I start to analyse get_all_table (for table TABLE) and think
>    about how to implement index in my current framework. 
>    What are the meanings of process_table, idx_field and idx_field2?
>    Those fields are used a lot in get_all_tables.

eh, if you look into definitions of different I_S tables you'll see that
process_table() is fill_variables(), fill_status(),
fill_schema_processlist(), and so on. That is process_table() fills the
table with the data in the old I_S implementation.

idx_field1 and idx_field2 - for TABLES table, for example, they're 1 and
2, that is TABLES table has an "index" over the columns 1 and 2,
TABLE_SCHEMA and TABLE_NAME.

> 4. All tables' rnd_pos and position are not finished yet for
>    non-sequential scan. After finishing rnd_next, I think they are
>    easy to implement by exacting a same fetching data function between
>    rnd_pos and rnd_next. I want to focus on table TABLE and index's
>    implementation these days.

I'd rather suggest you to do a complete implementation of TABLES first -
without an index but with rnd_pos. I call it complete, because it can be
used in all SQL queries, with order by, group by, etc.

When TABLES table will work, you can add an index, as an optimization.

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
GSoC Week 12 - I_S/P_S storage enginescut_tang27 Jul
  • Re: GSoC Week 12 - I_S/P_S storage engineSergei Golubchik27 Jul