Basic Optimizer

[GoogleCodeExporter]

The basic optimizer will

1) merge Location configurations at startup time, so that 2) there's a null 
merge at runtime.

3) Do dictionary lookups at startup time, using one thread's dictionary, and 
store the column id 
number and Ndb Column pointer for every used column.
4) Catch some configuration errors (table exists, but column or index name is 
bad) at startup time.

We still want mod_ndb to start even if some tables do not exist, (i.e. before 
you run "./run-test -s").

If tables are CREATEd, ALTERed, or DROPped at runtime, we need to handle this.

Original issue reported on code.google.com by john.david.duncan on 18 Sep 2007 at 7:03

[GoogleCodeExporter]

Before committing to put this in 1.1, do some benchmarks.  
Is there a performance gain? 
How bad are the ALTER TABLE issues? 

Set a flag in the dir structure to indicate whether the column lookups have 
happened.  At runtime, if we don't 
have the column indexes (i.e. the table has been newly created since startup), 
can we run without them?  Or 
does that make the source code too tangled?

Original comment by john.david.duncan on 24 Sep 2007 at 4:11

[GoogleCodeExporter]

Original comment by john.david.duncan on 1 Oct 2007 at 7:03

• Changed state: Started

[GoogleCodeExporter]

Original comment by john.david.duncan on 28 Dec 2007 at 5:08

• Added labels: Milestone-1.2
• Removed labels: Milestone-1.1

[GoogleCodeExporter]

If the data dictionary changes, and you execute a query, you will get error 
241, Invalid Schema Object Version.

Original comment by john.david.duncan on 17 Apr 2008 at 8:53