~drizzle-trunk/drizzle/development

« back to all changes in this revision

Viewing changes to docs/analyze.rst

  • Committer: Prafulla Tekawade
  • Date: 2010-07-13 16:07:35 UTC
  • mto: (1662.1.4 rollup)
  • mto: This revision was merged to the branch mainline in revision 1664.
  • Revision ID: prafulla_t@users.sourceforge.net-20100713160735-2fsdtrm3azayuyu1
This bug is simillar to mysql bug 36133
http://bugs.mysql.com/bug.php?id=36133

Taking changes from that fix.

  - The problem was that the range optimizer evaluated constant expressions, 
    and among them it would try to evaluate IN-subquery predicates slated for
    handling with materialization strategy. However, these predicates require
    that parent_join->setup_subquery_materialization() is invoked before one
    attempts to evaluate them.
  
  - Fixed by making the range optimizer not to evaluate expressions that have
    item->is_expensive() == TRUE (these are materialization subqueries and 
    stored function calls). This should also resolve the problem that EXPLAIN 
    may be too long. 
    This change cuts off some opportunities for range optimizer, but this is 
    the price we're willing to pay for separation of query optimization and
    execution. 

Show diffs side-by-side

added added

removed removed

Lines of Context:
1
 
ANALYZE
2
 
=======
3
 
 
4
 
ANALYZE TABLE table_name [, table_name] ...
5
 
 
6
 
ANALYZE TABLE read locks a table, and then analyzes and stores the key distribution for a table.
7
 
 
8
 
.. todo::
9
 
 
10
 
   is read lock always true?
11
 
 
12
 
.. todo::
13
 
   
14
 
   some engines don't perform an explicit gathering of statistics when
15
 
   you type ANALYZE. e.g. innobase (which only copies it's current estimate).
16
 
   Only recently did I add this to HailDB so that it does go and do the index
17
 
   dives on ANALYZE.