Commit graph

7 commits

Author SHA1 Message Date
unknown
445fcaa81a MWL#68 efficient partial matching
- Added an initial set of feature-specific test cases
- Handled the special case where the materialized subquery of an
  IN predicates consists of only NULL values.
- Fixed a bug where making Item_in_subselect a constant,
  didn't respect its null_value value.
2011-07-15 00:23:57 +03:00
unknown
1e6bd6b4df Fix bug lp:809266
Analysis:
This is a bug in MWL#68, where it was incorrectly assumed
that if there is a match in the only non-null key, then
if there is a covering NULL row on all remaining NULL-able
columns there is a partial match. However, this is not the case,
because even if there is such a null-only sub-row, it is not
guaranteed to be part of the matched sub-row. The matched sub-row
and the NULL-only sub-row may be parts of different rows.

In fact there are two cases:
- there is a complete row with only NULL values, and
- all nullable columns contain only NULL values.

These two cases were incorrectly mixed up in the class member
  subselect_partial_match_engine::covering_null_row_width.


Solution:
The solution is to:
- split covering_null_row_width into two members:
  has_covering_null_row, and has_covering_null_columns, and
- take into account each state during initialization and
  execution.
2011-07-14 00:15:07 +03:00
unknown
990584d73a Fixed bug lp:809245
In addition to the bug fix explained below, the patch performs
few renames, and adds some comments to avoid similar problems.

Analysis:
The failed assert was due to a bug in MWL#68, where it was
incorrectly assumed that the size of the bitmap
subselect_rowid_merge_engine::null_only_columns should be
the same as the size of the array of Ordered_keys.

The bitmap null_only_columns contains bits to mark columns
that contain only NULLs. Therefore the indexes of the bits
to be set in null_only_columns are different from the indexes
of the Ordered_keys. If there is a NULL-only column that appears
in a table after the last partial match column with Ordered_key,
this NULL-only column would require setting a bit with index
bigger than the size of the bitmap null_only_columns.

Accessing such a bit caused the failed assert.

Solution:
Upon analysis, it turns out that null_only_columns is not needed
at all, because we are looking for partial matches, and having
such columns guarantees that there is a partial match for any
corresponding outer value.

Therefore the patch removes
  subselect_rowid_merge_engine::null_only_columns.
2011-07-13 17:09:09 +03:00
unknown
0574bc894b Fix LP BUG#680058
Analysis:
The send_data method of the result sink class used to collect
data statistics about materialized subqueries incorrectly assumed
that duplicate rows are removed prior to calling send_data. As
a result the collected statistics was wrong, which resulted in
an incorrect maximal number of keys in the Ordered_key buffer.
  
Solution:
Try to insert each row into the materialized temp table before
collecting statistics, and if the insertion results in a duplicate
row, do not count the current row.
2010-11-25 00:34:50 +02:00
unknown
3bdede3c67 Fixed LP bug #613009
The set of Ordered keys of a rowid merge engine is dense. Thus when
we decide not to create a key for a column that has only NULLs, this
column shouldn't be counted.

Notice that the caller has already precomputed the correct total
number of keys that should be created.
2010-10-27 16:28:19 +03:00
unknown
b4d5f30a86 Fixed LP bug #601156
The cause for this bug is that MariaDB 5.3 still processes derived tables
(subqueries in the FROM clause) by fully executing them during the parse
phase. This will be remedied by MWL#106 once merged into the main 5.3.

The assert statement is triggered when MATERIALIZATION is ON for EXPLAIN
EXTENDED for derived tables with an IN subquery as follows:
- mysql_parse calls JOIN::exec for the derived table as if it is regular
  execution (not explain).
- When materialization is ON, this call goes all the way to
  subselect_hash_sj_engine::exec, which creates a partial match engine
  because of NULL presence.
- In order to proceed with normal execution, the hash_sj engine substitutes
  itself with the created partial match engine.
- After the parse phase it turns out that this execution was part of
  EXPLAIN EXTENDED, which in turn calls
  Item_cond::print -> ... -> Item_subselect::print,
  which calls engine->print().
  Since subselect_hash_sj_engine::exec substituted the current
  Item_subselect engine with a  partial match engine, eventually we call
  its ::print() method. However the partial match engines are designed only
  for execution, hence there is no implementation of this print() method.

The fix temporarily removes the assert, until this code is merged with
MWL#106.
2010-10-26 14:55:42 +03:00
unknown
f5ecf70819 Fixed LP bug #608744
The bug is a result of the following change by Monty:
  Revision Id: monty@askmonty.org-20100716073301-gstby2062nqd42qv
  Timestamp: Fri 2010-07-16 10:33:01 +0300
Where Monty changed the queues interface and implementation.

The fix adjusts the queue_remove call to the new interface.


mysql-test/r/subselect_partial_match.result:
  Added new file for tests related to MWL#89.
mysql-test/t/subselect_partial_match.test:
  Added new file for tests related to MWL#89.
2010-08-30 11:07:16 +03:00