This worklog has been replaced with mariadb.org/jira

This site is here for historical purposes only. Do not add or edit tasks here!

 
 
 

WorkLog Frontpage Log in / Register
High-Level Description | Task Dependencies | High-Level Specification | Low-Level Design | File Attachments | User Comments | Time Estimates | Funding and Votes | Progress Reports

 Subquery optimization: Avoid recalculating subquery if external fields values found in subquery cache
Title
Task ID66
Queue
Version
Status
Priority
Copies to
Created bySanja25 Nov 2009Done
Supervisor   
Lead Architect    
Architecture Review  
Implementor  
Code Review  
QA  
Documentation  
 High-Level Description
The goal of this task is to optimize evaluation of subqueries and subquery
predicates by storing the results of a correlated subquery together with
correlation parameters in a cache and reusing those results for the same sets of
parameters.

Here's what is to be done in this task in more details:

Collect all outer items/references (left part of the subquiery and outer
references inside the subquery) in key string. Compare the string (which
represents certain value set of the references) against values in hash table and
return cached result of subquery if the reference values combination has already
been used.

For example in the following subquery:
(L1, L2) IN (SELECT A, B FROM T WHERE T.F1>OTER_FIELD)
set of references to look into the subquery cache is (L1, L2, OTER_FIELD).

The subquery cache should be implemented as simple LRU connected to the subquery.

Size of the subquery cache (in number of results (but maybe in used memory
amount)) is limited by session variable (query parameter?).
 Task Dependencies
Others waiting for Task 66Task 66 is waiting forGraph
91 MariaDB 5.3
 
 High-Level Specification
Attach subquery cache to each Item_subquery. Interface should allow to use hash
or temporary table inside.


To check/discuss:
-----------------
* Will there be any means to measure subquery cache hit rate?
* MySQL-6.0 has a one-element predicate result cache. It is called "left
  expression cache", grep for left_expr_cache in sql/item_subselect.*  
  When this WL is merged with 6.0's optimizations, these two caches will 
  need to be unified somehow.


<contents>
1. Scope of the task
2. Data structure used for the cache
3. Cache size
4. Interplay with other subquery optimizations
5. User interface
</contents>

1. Scope of the task
--------------------
This WL should handle all subquery predicates, i.e. it should handle these
cases:

  outer_expr IN (SELECT correlated_select)
  outer_expr $CMP$ ALL/ANY (SELECT correlated_select)
  EXISTS (SELECT correlated_select)
  scalar-context subquery: (SELECT correlated_select)

The cache will maintain 
  
  (outer_expr, correlation_references)-> subquery_item_result 

mapping, where
- correlation_references is a list of tablename.column_name that are referred 
  from the correlated_select but tablename is a table that is ouside the
  subquery. 
- subquery_item_result is 'bool' for subquery predicates, and is of
some scalar or  ROW(scalar1,...scalarN) type for scalar-context subquery.

We don't support cases when outer_expr or correlation_references are blobs.

All subquery predicates are cached. That is, if one subquery predicate is
located within another, both of them will have caches  (one option to reduce
cache memory usage was to use cache only for the upper-most select. we decided
against it).

2. Data structure used for the cache
------------------------------------
There are two data structures available in the codebase that will allow fast 
equality lookups:

1. HASH (mysys/hash.c) tables
2. Temporary tables (the ones that are used for e.g. GROUP BY)

None of them has any support for element eviction on overflow (using LRU or
some other policy). 

Query cache and MyISAM/Maria's key/page cache ought to support some eviction 
mechanism, but code-wise it is not readily reusable, one will need to factor 
it out (or copy it).

We choose to use #2, and not to have any eviction policy. See subsequent
sections for details and reasoning behind the decision.

3. Cache size
-------------
Typically, a cache has some maximum size and a policy which is used to
select a cache entry for removal when the cache becomes full (e.g. find 
and remove the least [recently] used entry)

For this WL entry we will use a cache of infinite size. The reasoning behind
this is that:
- is is easy to do: we have temporary tables that can grow to arbitrarily
  large size while still providing the same insert/lookup interface.
- it suits us: unless the subquery is resolved with one index lookup,
  hitting the cache would be many times cheaper than re-running the
  subquery, so cache is worth having.

4. Interplay with other subquery optimizations
----------------------------------------------
* This WL entry should not care about IN->EXISTS transformation: caching for 
  IN subquery and result of its conversion to EXISTS would work in the same
  way.

* This optimization is orthogonal to <=>ANY -> MIN/MAX rewrite (it will
  work/be useful irrespectively of whether the rewrite has been performed or
  not)

* TODO: compare this with materialization for uncorrelated IN-subqueries. Is 
  this basically the same?
  A: no, it is not:
  - IN-Materialization has to perform full materialization before it can 
    do the first subquery evaluation. This WL's code has almost no startup 
    costs.
  - This optimization has temp.table of (corr_reference, predicate_value),
    while IN-materialization will have (corr_reference) only.

5. User interface
-----------------
* There will be an @@optimizer_switch flag to turn this optimization on and
  off (TODO: name of the flag?)

* TODO: how do we show this in EXPLAIN [EXTENDED]?  The most easiest is to 
  print something in the warning text of EXPLAIN EXTEDED that would indicate 
  use of cache.

* temporary table sizing (max size for heap table, whether to use MyISAM or
  Maria) will be controlled with common temp.table control variables.
 Low-Level Design
* Target version: base on mysql-5.3 code

All items on which subquery depend could be collected in
st_select_lex::register_dependency_item (indirect reference)

Temporary table index should be created by all fields except result field
(TABLE::add_tmp_key).

How to fill the temptable
-------------------------
Can reuse approach from SJ-Materialization. Its code is in end_sj_materialize()
and is supposed to be quite trivial.

How to make lookups into temptable
----------------------------------
We'll reuse approach used by SJ-Materialization in 6.0. 

Setup process
~~~~~~~~~~~~~
Setup is performed in the same way as in setup_sj_materialization(),
see the code that starts these lines:

    /*
      Create/initialize everything we will need to index lookups into the
      temptable.
    */

and ends at this line:

      Remove the injected semi-join IN-equalities from join_tab conds. This

<questionable>
We'll also need to check equalities, i.e. do an equivalent of this:

    if (!(sjm->in_equality= create_subq_in_equalities(thd, sjm,
                                                      emb_sj_nest->sj_subq_pred)))
      DBUG_RETURN(TRUE); /* purecov: inspected */

Question: or perhaps that is not necessarry?
</questionable>

Doing the lookup
~~~~~~~~~~~~~~~~
SJ-Materialization does lookup in sub_select_sjm(), with this code:

    /* Do index lookup in the materialized table */
    if ((res= join_read_key2(join_tab, sjm->table, sjm->tab_ref)) == 1)
      DBUG_RETURN(NESTED_LOOP_ERROR); /* purecov: inspected */
    if (res || !sjm->in_equality->val_int())
      DBUG_RETURN(NESTED_LOOP_NO_MORE_ROWS);

The code in this WL will use the same approach except eqality which will be
created according to field type (some types do not need it)

Extracting the value of the subquery predicate
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The goal of making the lookup is to get the value of subquery predicate.
This is done by creating an Item_field $I which refers to appropriate
temporary table's field and then subquery_predicate->val_int() will invoke
$I->val_int(),  subquery_predicate->val_str() will invoke $I->val_str() and so 
forth.

Caching the subquery in Item tree
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

We use Item::transform to put caching Item (Item_cache_wrapper) before the
subquery (Item_subquery* or Item_in_optimizer). For this we add new transformer
method ::cache_insert_transformer.
 File Attachments
 NameTypeSizeByDate
 User Comments
 Time Estimates
NameHours WorkedLast Updated
Total0 
 Hrs WorkedProgressCurrentOriginal
Total000
 
 Funding and Votes
Votes: 0: 0%
 Make vote: Useless    Nice to have    Important    Very important    

Funding: 0 offers, total 0 Euro
 Progress Reports
(Sanja - Mon, 22 Nov 2010, 15:55
    
Status updated.
--- /tmp/wklog.66.old.23255	2010-11-22 15:55:33.000000000 +0000
+++ /tmp/wklog.66.new.23255	2010-11-22 15:55:33.000000000 +0000
@@ -1,2 +1,2 @@
-In-Documentation
+Complete
 

(Sanja - Tue, 16 Nov 2010, 14:05
    
Category updated.
--- /tmp/wklog.66.old.15992	2010-11-16 14:05:29.000000000 +0000
+++ /tmp/wklog.66.new.15992	2010-11-16 14:05:29.000000000 +0000
@@ -1,2 +1,2 @@
-Server-RawIdeaBin
+Server-Sprint
 

(Sanja - Tue, 16 Nov 2010, 14:05
    
Status updated.
--- /tmp/wklog.66.old.15992	2010-11-16 14:05:29.000000000 +0000
+++ /tmp/wklog.66.new.15992	2010-11-16 14:05:29.000000000 +0000
@@ -1,2 +1,2 @@
-Assigned
+In-Documentation
 

(Psergey - Sat, 09 Oct 2010, 10:52
    
Dependency created: WL#91 now depends on WL#66

(Sergei - Thu, 01 Jul 2010, 06:01
    
Category updated.
--- /tmp/wklog.66.old.28392	2010-07-01 06:01:53.000000000 +0000
+++ /tmp/wklog.66.new.28392	2010-07-01 06:01:53.000000000 +0000
@@ -1 +1 @@
-Client-Sprint
+Server-RawIdeaBin

(Sergei - Thu, 01 Jul 2010, 06:01
    
Version updated.
No change.

(Sergei - Thu, 01 Jul 2010, 06:01
    
Version updated.
--- /tmp/wklog.66.old.28392	2010-07-01 06:01:53.000000000 +0000
+++ /tmp/wklog.66.new.28392	2010-07-01 06:01:53.000000000 +0000
@@ -1 +1 @@
-9.x
+Server-9.x

(Sanja - Thu, 24 Jun 2010, 06:01
    
Low Level Design modified.
--- /tmp/wklog.66.old.19228	2010-06-24 06:01:35.000000000 +0000
+++ /tmp/wklog.66.new.19228	2010-06-24 06:01:35.000000000 +0000
@@ -1,10 +1,10 @@
-* Target version: base on mysql-5.2 code
+* Target version: base on mysql-5.3 code
 
 All items on which subquery depend could be collected in
-st_select_lex::mark_as_dependent (direct of indirect reference?)
+st_select_lex::register_dependency_item (indirect reference)
 
 Temporary table index should be created by all fields except result field
-(TMP_TABLE_PARAM::keyinfo).
+(TABLE::add_tmp_key).
 
 How to fill the temptable
 -------------------------
@@ -49,7 +49,8 @@
     if (res || !sjm->in_equality->val_int())
       DBUG_RETURN(NESTED_LOOP_NO_MORE_ROWS);
 
-The code in this WL will use the same approach
+The code in this WL will use the same approach except eqality which will be
+created according to field type (some types do not need it)
 
 Extracting the value of the subquery predicate
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -58,3 +59,11 @@
 temporary table's field and then subquery_predicate->val_int() will invoke
 $I->val_int(),  subquery_predicate->val_str() will invoke $I->val_str() and so 
 forth.
+
+Caching the subquery in Item tree
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+We use Item::transform to put caching Item (Item_cache_wrapper) before the
+subquery (Item_subquery* or Item_in_optimizer). For this we add new transformer
+method ::cache_insert_transformer.
+

(Guest - Sun, 13 Jun 2010, 16:51
    
Dependency deleted: WL#91 no longer depends on WL#66

(Igor - Wed, 10 Mar 2010, 21:29
    
High Level Description modified.
--- /tmp/wklog.66.old.32188	2010-03-10 21:29:16.000000000 +0000
+++ /tmp/wklog.66.new.32188	2010-03-10 21:29:16.000000000 +0000
@@ -1,3 +1,10 @@
+The goal of this task is to optimize evaluation of subqueries and subquery
+predicates by storing the results of a correlated subquery together with
+correlation parameters in a cache and reusing those results for the same sets of
+parameters.
+
+Here's what is to be done in this task in more details:
+
 Collect all outer items/references (left part of the subquiery and outer
 references inside the subquery) in key string. Compare the string (which
 represents certain value set of the references) against values in hash table and

(Igor - Wed, 10 Mar 2010, 21:13
    
Dependency created: WL#91 now depends on WL#66

(Igor - Wed, 10 Mar 2010, 21:12
    
Category updated.
--- /tmp/wklog.66.old.31558	2010-03-10 21:12:50.000000000 +0000
+++ /tmp/wklog.66.new.31558	2010-03-10 21:12:50.000000000 +0000
@@ -1 +1 @@
-Server-BackLog
+Client-Sprint

(Igor - Wed, 10 Mar 2010, 21:12
    
Version updated.
--- /tmp/wklog.66.old.31558	2010-03-10 21:12:50.000000000 +0000
+++ /tmp/wklog.66.new.31558	2010-03-10 21:12:50.000000000 +0000
@@ -1 +1 @@
-Server-5.3
+9.x

(Monty - Fri, 29 Jan 2010, 19:07
    
Version updated.
--- /tmp/wklog.66.old.5893	2010-01-29 19:07:10.000000000 +0200
+++ /tmp/wklog.66.new.5893	2010-01-29 19:07:10.000000000 +0200
@@ -1 +1 @@
-Server-5.2
+Server-5.3

(Psergey - Wed, 20 Jan 2010, 14:50
    
High-Level Specification modified.
--- /tmp/wklog.66.old.26873	2010-01-20 14:50:41.000000000 +0200
+++ /tmp/wklog.66.new.26873	2010-01-20 14:50:41.000000000 +0200
@@ -4,7 +4,6 @@
 
 To check/discuss:
 -----------------
-* Do we put subquery cache on all levels of subqueries or on highest level only
 * Will there be any means to measure subquery cache hit rate?
 * MySQL-6.0 has a one-element predicate result cache. It is called "left
   expression cache", grep for left_expr_cache in sql/item_subselect.*  
@@ -41,7 +40,12 @@
 - subquery_item_result is 'bool' for subquery predicates, and is of
 some scalar or  ROW(scalar1,...scalarN) type for scalar-context subquery.
 
-We dont support cases when outer_expr or correlation_references are blobs.
+We don't support cases when outer_expr or correlation_references are blobs.
+
+All subquery predicates are cached. That is, if one subquery predicate is
+located within another, both of them will have caches  (one option to reduce
+cache memory usage was to use cache only for the upper-most select. we decided
+against it).
 
 2. Data structure used for the cache
 ------------------------------------

(Psergey - Wed, 20 Jan 2010, 13:07
    
High-Level Specification modified.
--- /tmp/wklog.66.old.17649	2010-01-20 13:07:07.000000000 +0200
+++ /tmp/wklog.66.new.17649	2010-01-20 13:07:07.000000000 +0200
@@ -3,7 +3,13 @@
 
 
 To check/discuss:
- To put subquery cache on all levels of subqueries or on highest level only.
+-----------------
+* Do we put subquery cache on all levels of subqueries or on highest level only
+* Will there be any means to measure subquery cache hit rate?
+* MySQL-6.0 has a one-element predicate result cache. It is called "left
+  expression cache", grep for left_expr_cache in sql/item_subselect.*  
+  When this WL is merged with 6.0's optimizations, these two caches will 
+  need to be unified somehow.
 
 
 <contents>

(Psergey - Mon, 18 Jan 2010, 16:40
    
Low Level Design modified.
--- /tmp/wklog.66.old.24899	2010-01-18 16:40:16.000000000 +0200
+++ /tmp/wklog.66.new.24899	2010-01-18 16:40:16.000000000 +0200
@@ -1,3 +1,5 @@
+* Target version: base on mysql-5.2 code
+
 All items on which subquery depend could be collected in
 st_select_lex::mark_as_dependent (direct of indirect reference?)
 

(Psergey - Mon, 18 Jan 2010, 16:37
    
Low Level Design modified.
--- /tmp/wklog.66.old.24586	2010-01-18 16:37:07.000000000 +0200
+++ /tmp/wklog.66.new.24586	2010-01-18 16:37:07.000000000 +0200
@@ -4,6 +4,11 @@
 Temporary table index should be created by all fields except result field
 (TMP_TABLE_PARAM::keyinfo).
 
+How to fill the temptable
+-------------------------
+Can reuse approach from SJ-Materialization. Its code is in end_sj_materialize()
+and is supposed to be quite trivial.
+
 How to make lookups into temptable
 ----------------------------------
 We'll reuse approach used by SJ-Materialization in 6.0. 

(Psergey - Mon, 18 Jan 2010, 16:34
    
Low Level Design modified.
--- /tmp/wklog.66.old.24328	2010-01-18 16:34:19.000000000 +0200
+++ /tmp/wklog.66.new.24328	2010-01-18 16:34:19.000000000 +0200
@@ -32,8 +32,8 @@
 Question: or perhaps that is not necessarry?
 </questionable>
 
-Execution process
-~~~~~~~~~~~~~~~~~
+Doing the lookup
+~~~~~~~~~~~~~~~~
 SJ-Materialization does lookup in sub_select_sjm(), with this code:
 
     /* Do index lookup in the materialized table */
@@ -42,4 +42,12 @@
     if (res || !sjm->in_equality->val_int())
       DBUG_RETURN(NESTED_LOOP_NO_MORE_ROWS);
 
+The code in this WL will use the same approach
 
+Extracting the value of the subquery predicate
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+The goal of making the lookup is to get the value of subquery predicate.
+This is done by creating an Item_field $I which refers to appropriate
+temporary table's field and then subquery_predicate->val_int() will invoke
+$I->val_int(),  subquery_predicate->val_str() will invoke $I->val_str() and so 
+forth.

(Psergey - Mon, 18 Jan 2010, 16:23
    
Low Level Design modified.
--- /tmp/wklog.66.old.23203	2010-01-18 16:23:18.000000000 +0200
+++ /tmp/wklog.66.new.23203	2010-01-18 16:23:18.000000000 +0200
@@ -31,3 +31,15 @@
 
 Question: or perhaps that is not necessarry?
 </questionable>
+
+Execution process
+~~~~~~~~~~~~~~~~~
+SJ-Materialization does lookup in sub_select_sjm(), with this code:
+
+    /* Do index lookup in the materialized table */
+    if ((res= join_read_key2(join_tab, sjm->table, sjm->tab_ref)) == 1)
+      DBUG_RETURN(NESTED_LOOP_ERROR); /* purecov: inspected */
+    if (res || !sjm->in_equality->val_int())
+      DBUG_RETURN(NESTED_LOOP_NO_MORE_ROWS);
+
+

(Psergey - Mon, 18 Jan 2010, 16:22
    
Low Level Design modified.
--- /tmp/wklog.66.old.23076	2010-01-18 16:22:07.000000000 +0200
+++ /tmp/wklog.66.new.23076	2010-01-18 16:22:07.000000000 +0200
@@ -4,3 +4,30 @@
 Temporary table index should be created by all fields except result field
 (TMP_TABLE_PARAM::keyinfo).
 
+How to make lookups into temptable
+----------------------------------
+We'll reuse approach used by SJ-Materialization in 6.0. 
+
+Setup process
+~~~~~~~~~~~~~
+Setup is performed in the same way as in setup_sj_materialization(),
+see the code that starts these lines:
+
+    /*
+      Create/initialize everything we will need to index lookups into the
+      temptable.
+    */
+
+and ends at this line:
+
+      Remove the injected semi-join IN-equalities from join_tab conds. This
+
+<questionable>
+We'll also need to check equalities, i.e. do an equivalent of this:
+
+    if (!(sjm->in_equality= create_subq_in_equalities(thd, sjm,
+                                                      emb_sj_nest->sj_subq_pred)))
+      DBUG_RETURN(TRUE); /* purecov: inspected */
+
+Question: or perhaps that is not necessarry?
+</questionable>

(Psergey - Tue, 12 Jan 2010, 18:39
    
High-Level Specification modified.
--- /tmp/wklog.66.old.31666	2010-01-12 18:39:43.000000000 +0200
+++ /tmp/wklog.66.new.31666	2010-01-12 18:39:43.000000000 +0200
@@ -4,3 +4,99 @@
 
 To check/discuss:
  To put subquery cache on all levels of subqueries or on highest level only.
+
+
+<contents>
+1. Scope of the task
+2. Data structure used for the cache
+3. Cache size
+4. Interplay with other subquery optimizations
+5. User interface
+</contents>
+
+1. Scope of the task
+--------------------
+This WL should handle all subquery predicates, i.e. it should handle these
+cases:
+
+  outer_expr IN (SELECT correlated_select)
+  outer_expr $CMP$ ALL/ANY (SELECT correlated_select)
+  EXISTS (SELECT correlated_select)
+  scalar-context subquery: (SELECT correlated_select)
+
+The cache will maintain 
+  
+  (outer_expr, correlation_references)-> subquery_item_result 
+
+mapping, where
+- correlation_references is a list of tablename.column_name that are referred 
+  from the correlated_select but tablename is a table that is ouside the
+  subquery. 
+- subquery_item_result is 'bool' for subquery predicates, and is of
+some scalar or  ROW(scalar1,...scalarN) type for scalar-context subquery.
+
+We dont support cases when outer_expr or correlation_references are blobs.
+
+2. Data structure used for the cache
+------------------------------------
+There are two data structures available in the codebase that will allow fast 
+equality lookups:
+
+1. HASH (mysys/hash.c) tables
+2. Temporary tables (the ones that are used for e.g. GROUP BY)
+
+None of them has any support for element eviction on overflow (using LRU or
+some other policy). 
+
+Query cache and MyISAM/Maria's key/page cache ought to support some eviction 
+mechanism, but code-wise it is not readily reusable, one will need to factor 
+it out (or copy it).
+
+We choose to use #2, and not to have any eviction policy. See subsequent
+sections for details and reasoning behind the decision.
+
+3. Cache size
+-------------
+Typically, a cache has some maximum size and a policy which is used to
+select a cache entry for removal when the cache becomes full (e.g. find 
+and remove the least [recently] used entry)
+
+For this WL entry we will use a cache of infinite size. The reasoning behind
+this is that:
+- is is easy to do: we have temporary tables that can grow to arbitrarily
+  large size while still providing the same insert/lookup interface.
+- it suits us: unless the subquery is resolved with one index lookup,
+  hitting the cache would be many times cheaper than re-running the
+  subquery, so cache is worth having.
+
+4. Interplay with other subquery optimizations
+----------------------------------------------
+* This WL entry should not care about IN->EXISTS transformation: caching for 
+  IN subquery and result of its conversion to EXISTS would work in the same
+  way.
+
+* This optimization is orthogonal to <=>ANY -> MIN/MAX rewrite (it will
+  work/be useful irrespectively of whether the rewrite has been performed or
+  not)
+
+* TODO: compare this with materialization for uncorrelated IN-subqueries. Is 
+  this basically the same?
+  A: no, it is not:
+  - IN-Materialization has to perform full materialization before it can 
+    do the first subquery evaluation. This WL's code has almost no startup 
+    costs.
+  - This optimization has temp.table of (corr_reference, predicate_value),
+    while IN-materialization will have (corr_reference) only.
+
+5. User interface
+-----------------
+* There will be an @@optimizer_switch flag to turn this optimization on and
+  off (TODO: name of the flag?)
+
+* TODO: how do we show this in EXPLAIN [EXTENDED]?  The most easiest is to 
+  print something in the warning text of EXPLAIN EXTEDED that would indicate 
+  use of cache.
+
+* temporary table sizing (max size for heap table, whether to use MyISAM or
+  Maria) will be controlled with common temp.table control variables.
+

(Psergey - Mon, 11 Jan 2010, 13:25
    
As of today, there is code that
- collects outside references 
- creates a temporary table with index that would allow for fast lookups.

there is no code to
- fill the temporary table 
- make lookups into it

(Sanja - Fri, 11 Dec 2009, 15:09
    
High-Level Specification modified.
--- /tmp/wklog.66.old.28164	2009-12-11 15:09:15.000000000 +0200
+++ /tmp/wklog.66.new.28164	2009-12-11 15:09:15.000000000 +0200
@@ -3,4 +3,4 @@
 
 
 To check/discuss:
-Are there sens to put subquery cache on all levels of subqueries of on highest.
+ To put subquery cache on all levels of subqueries or on highest level only.

(Sanja - Fri, 11 Dec 2009, 15:08
    
Low Level Design modified.
--- /tmp/wklog.66.old.28072	2009-12-11 15:08:16.000000000 +0200
+++ /tmp/wklog.66.new.28072	2009-12-11 15:08:16.000000000 +0200
@@ -1 +1,6 @@
+All items on which subquery depend could be collected in
+st_select_lex::mark_as_dependent (direct of indirect reference?)
+
+Temporary table index should be created by all fields except result field
+(TMP_TABLE_PARAM::keyinfo).
 

(Sanja - Fri, 11 Dec 2009, 15:05
    
High-Level Specification modified.
--- /tmp/wklog.66.old.27795	2009-12-11 15:05:04.000000000 +0200
+++ /tmp/wklog.66.new.27795	2009-12-11 15:05:04.000000000 +0200
@@ -1 +1,6 @@
+Attach subquery cache to each Item_subquery. Interface should allow to use hash
+or temporary table inside.
 
+
+To check/discuss:
+Are there sens to put subquery cache on all levels of subqueries of on highest.


Report Generator:
 
Saved Reports:

WorkLog v4.0.0
  © 2010  Sergei Golubchik and Monty Program AB
  © 2004  Andrew Sweger <yDNA@perlocity.org> and Addnorya
  © 2003  Matt Wagner <matt@mysql.com> and MySQL AB