Bugfix revert some commit #5
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Remove the hash_join=off optimizer switch; it causes problems with certain information schema views, and it will go away anyway shortly, when the pre-iterator executor (and thus also BNL) is removed. Change-Id: I3779fbc6be57e7fcf6533a32d538cabf3941e5f4
Subquery materialization used to require inner and outer types to match, now let's allow _some_ cases of difference: - ok if inner is numeric (as there's a well-defined way to cast the outer to a number) - otherwise, require same collation, and: - ok if inner is temporal (as there's a well-defined way to cast the outer to a temporal) - ok if two strings. So, compared to before, we have relaxed numbers, BIT and temporal. The motivation is that an INT could be compared to a SUM of INT (which is a DECIMAL) without resorting to IN-to-EXISTS. Another motivation is to make decisions simpler to anticipate, for the user and us devs. A new test file is added, based on Harsha's previous patches. It compares combinations of types when used with an equi-join and when used with IN(subquery). Results have been validated against trunk, we only have EXPLAIN changes, showing that subq-mat and semijoin-mat are used more often. One exception: compared to trunk, the queries which look up a TIME into an indexed TIMESTAMP now give a good result, because they now use subquery materialization, while IN-to-EXISTS has a bug (bug 75644). opt_hints_subquery: changed test to maintain intention. Approved by: Roy Lyseng <roy.lyseng@oracle.com> Change-Id: Ia7af06f74ea0ca1f16040195952d7fb1fe9e4153
…SPACE_PAGE_SIZE) Problem: There was an attempt to access an LOB via a LOB null reference. Solution: Check whether the LOB reference is null before accessing it. rb#23454 approved by Rahul Agarkar <rahul.agarkar@oracle.com>
Problem:
* When temptable_max_ram limit is reached, server will report
Out-of-Memory to connected client(s) instead of falling back to
disk-based storage.
Analysis:
* TempTable storage-engine has been (wrongly) reporting
Result::OUT_OF_MEMORY no matter what underlying operation failed.
* Underlying failures can be one of the following:
* Result::OUT_OF_MEMORY
* In event of RAM exhaustion.
* Result::RECORD_FILE_FULL
* In event of temptable_max_ram limit reached or MMAP-disk
exhaustion.
* Some other runtime exception (which is not of Result:: type)
* In event that something else throws, e.g. any of the steps
during the new temporary table instantiation.
* Optimizer only handles the Result::RECORD_FILE_FULL code-path
(aka HA_ERR_RECORD_FILE_FULL), but not the (unexpected)
Result::OUT_OF_MEMORY (aka HA_ERR_OUT_OF_MEM).
* MTR test against the Result::RECORD_FILE_FULL use-case silently
stopped working
* There is no failure but the test itself was not hitting the correct
code-path:
* TempTable SE was ought to be utilized but it stopped being so
after optimizer introduced new executor which in certain scenario
is skipping the materialization.
Solution:
* Fix TempTable handler interface to distinguish between RAM- and
MMAP-related failures.
* Implement new suite of unit-tests to test this behavior at
TempTable::Handler interface level.
* Fix MTR test to make the Result::RECORD_FILE_FULL code-path gets
triggered again.
* Stabilize MTR test to make it future-proof by:
* Re-writing the SQL query which is more or less guaranteed to
result with TempTable utilization
AND
* Using EXPLAIN FORMAT=tree <stmt> to actually assert if TempTable
is not being utilized
Reviewed-by: Marcin Babij <marcin.babij@oracle.com>
…LOB_FIRST AT ZLOB0READ.CC Problem: Consider the scenario where the zlob (compressed LOB) is stored in old format using a single zlib stream. The purge will process this zlob by removing the first page of the LOB repeatedly. There seems to be a race condition b/w purge thread and an update thread that is reusing a delete marked record. Because of this the update thread sees a lob whose first page is of type FIL_PAGE_TYPE_ZBLOB2, which suggests that the zlob is partially purged. The test case just demonstrates that it is possible for the first page of LOB to be FIL_PAGE_TYPE_ZBLOB2 because of partial purging. Solution: I think we can remove the failing assert. rb#23293 approved by Kuba <jakub.lopuszanski@oracle.com>
…UALS_TO(SPACE_PAGE_SIZE)" This reverts commit fb069ce.
|
Steinar H. Gunderson seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account. You have signed the CLA already but the status is still pending? Let us recheck it. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.