KEY ACCOMPLISHMENTS LAST WEEK
Finished index definition in infoschema_discover.
I want to implement index in the last week, but I meet some problems, which
will be described in KEY CONCERNS.
Finished non-sequential scan (ORDER BY clause) for tables: TABLES, TRIGGERS,
COLLATION and COLUMN_PRIVILEGES. Those things are easy. The remaining
difficulty is index, but I have idea.
KEY TASKS THAT STALLED LAST WEEK
Behind the schedule. I am speeding up.
1. My index implementation is like this: TABLES has three indexes:
a.TABLE_SCHEMA; b.TABLE_NAME; c.TABLE_SCHEMA and TABLE_NAME.
When user performs "SELECT * FROM INFOSCHEMA.TABLES WHERE TABLE_SCHEMA =
'db_name'", etc. records_in_range will decide which
index to use. And in index functions(index_read_map, index_next_same)
will fetch right data. Does I_S storage engine support HA_ONLY_WHOLE_INDEX?
When users types: SELECT * FROM INFOSCHEM.TABLES WHERE TABLE_SCHEMA =
'db_name' AND TABLE_NAME = 'table_name'.
Does records_in_range perform twice, one for index a.(TABLE_SCHEMA) and
other is for c.(TABLE_SCHEMA and TABLE_NAME)? Or just one time for
c.(TABLE_SCHEMA and TABLE_NAME)?
2. I have defined index defintion for TABLES in infoschema_discover, and
"SHOW INDEX FROM INFOSCHEMA.TABLES" seems right.
But I run "SELECT * FROM INFOSCHEMA.TABLES WHERE TABLE_SCHEMA =
'db_name'; ", I_S storage engine won't perform records_in_range, even
index_flags, whatever I do in info() and scan_time().
What is the problem? What is the key point to cause index to use?
The problem is very urgent. If it is solved, the remaining is easy to
TASKS IN THE UPCOMING WEEK
To finish TABLES index at least. If I have time, to finish other tables
using index and their non-sequential scan.
|• GSoC Week 14 - I_S/P_S storage engine||Haihao Tang||10 Aug|