FB8-172: Add variable to disable full table/index scans #970
Conversation
This file contains 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
laurynas-biveinis
suggested changes
Feb 25, 2019
percona-ysorokin
suggested changes
Feb 25, 2019
inikep
force-pushed
the
FB8-172
branch
2 times, most recently
from
725d793 to
ae38647
Compare
|
PR was updated |
inikep
force-pushed
the
FB8-172
branch
2 times, most recently
from
47d811f to
f04ee34
Compare
inikep
changed the title
There was a problem hiding this comment.
@lth has imported this pull request. If you are a Facebook employee, you can view this diff on Phabricator.
There was a problem hiding this comment.
@hermanlee has imported this pull request. If you are a Facebook employee, you can view this diff on Phabricator.
There was a problem hiding this comment.
@hermanlee has imported this pull request. If you are a Facebook employee, you can view this diff on Phabricator.
hermanlee
force-pushed
the
fb-mysql-8.0.13
branch
from
e9926c3 to
c3bd1c6
Compare
|
@inikep has updated the pull request. Re-import the pull request |
There was a problem hiding this comment.
@hermanlee has imported this pull request. If you are a Facebook employee, you can view this diff on Phabricator.
lth
reviewed
Mar 22, 2019
share/errmsg-utf8.txt
Outdated
| @@ -18728,6 +18728,9 @@ ER_RPL_FAILED_IN_RLI_INIT_INFO | |||
| ER_SEMISYNC_FORCE_SHUTDOWN | |||
| eng "Force shutdown: Semi-sync master is being switched off while there are active un-acked transactions" | |||
|
|
|||
| ER_FULL_SCAN_DISABLED | |||
There was a problem hiding this comment.
We should reuse the 5.6 error number: 50077.
Jira issue: https://jira.percona.com/browse/FB8-172 Reference Patch: facebook@b90e801 Reference Patch: facebook@ecef4b2 ---------- facebook@b90e801 ---------- Add variable to disable full table/index scans Summary: There are cases where it is always unacceptable for a client to be doing full table scans. To prevent this from happening, add a new variable optimizer_full_scan. When it is turned off, it will return a new error code ER_FULL_SCAN_DISABLED. For best results, use with optimizer_force_index_for_range. Currently, it does not fallback to alternative plans because we check at the end of query planning. Originally Reviewed By: hermanlee fbshipit-source-id: 94fcd07 ---------- facebook@ecef4b2 ---------- Fix optimizer_full_scan to not error for explain queries Summary: EXPLAIN queries with derived tables do not populate select_options in the JOIN structure properly. This means that we could error if we tried to run an explain on a query with derived tables. Instead of reading from the JOIN struct, read from the LEX struct on the THD, as this is where the flag is original set on during query parsing. This bug also means that in upstream, we increment some status variables tracking full table scans despite the fact that only an explain statement was done. This seems to have been fixed in 8.0 though. Squash with: D7528820 fbshipit-source-id: b62bcf1
|
@inikep has updated the pull request. Re-import the pull request |
|
PR was updated with |
There was a problem hiding this comment.
@hermanlee has imported this pull request. If you are a Facebook employee, you can view this diff on Phabricator.
lth
approved these changes
Mar 26, 2019
facebook-github-bot
pushed a commit
that referenced
this pull request
Mar 30, 2019
Summary: Jira issue: https://jira.percona.com/browse/FB8-172 Reference Patch: b90e801 Reference Patch: ecef4b2 There are cases where it is always unacceptable for a client to be doing full table scans. To prevent this from happening, add a new variable optimizer_full_scan. When it is turned off, it will return a new error code ER_FULL_SCAN_DISABLED. For best results, use with optimizer_force_index_for_range. Currently, it does not fallback to alternative plans because we check at the end of query planning. EXPLAIN queries with derived tables do not populate select_options in the JOIN structure properly. This means that we could error if we tried to run an explain on a query with derived tables. Instead of reading from the JOIN struct, read from the LEX struct on the THD, as this is where the flag is original set on during query parsing. This bug also means that in upstream, we increment some status variables tracking full table scans despite the fact that only an explain statement was done. This seems to have been fixed in 8.0 though. Pull Request resolved: #970 Reviewed By: lth Differential Revision: D14567846 Pulled By: lth fbshipit-source-id: 9669768
inikep
pushed a commit
to inikep/mysql-5.6
that referenced
this pull request
Jun 23, 2023
facebook#970) Summary: Jira issue: https://jira.percona.com/browse/FB8-172 Reference Patch: facebook@b90e801 Reference Patch: facebook@ecef4b2 There are cases where it is always unacceptable for a client to be doing full table scans. To prevent this from happening, add a new variable optimizer_full_scan. When it is turned off, it will return a new error code ER_FULL_SCAN_DISABLED. For best results, use with optimizer_force_index_for_range. Currently, it does not fallback to alternative plans because we check at the end of query planning. EXPLAIN queries with derived tables do not populate select_options in the JOIN structure properly. This means that we could error if we tried to run an explain on a query with derived tables. Instead of reading from the JOIN struct, read from the LEX struct on the THD, as this is where the flag is original set on during query parsing. This bug also means that in upstream, we increment some status variables tracking full table scans despite the fact that only an explain statement was done. This seems to have been fixed in 8.0 though. Pull Request resolved: facebook#970 Reviewed By: lloyd Differential Revision: D14567846 Pulled By: lth
hermanlee
pushed a commit
to hermanlee/mysql-5.6
that referenced
this pull request
Oct 3, 2023
facebook#970) Summary: Jira issue: https://jira.percona.com/browse/FB8-172 Reference Patch: facebook@b90e801 Reference Patch: facebook@ecef4b2 There are cases where it is always unacceptable for a client to be doing full table scans. To prevent this from happening, add a new variable optimizer_full_scan. When it is turned off, it will return a new error code ER_FULL_SCAN_DISABLED. For best results, use with optimizer_force_index_for_range. Currently, it does not fallback to alternative plans because we check at the end of query planning. EXPLAIN queries with derived tables do not populate select_options in the JOIN structure properly. This means that we could error if we tried to run an explain on a query with derived tables. Instead of reading from the JOIN struct, read from the LEX struct on the THD, as this is where the flag is original set on during query parsing. This bug also means that in upstream, we increment some status variables tracking full table scans despite the fact that only an explain statement was done. This seems to have been fixed in 8.0 though. Pull Request resolved: facebook#970 Reviewed By: lloyd Differential Revision: D14567846 Pulled By: lth
hermanlee
pushed a commit
to hermanlee/mysql-5.6
that referenced
this pull request
Oct 18, 2023
facebook#970) Summary: Jira issue: https://jira.percona.com/browse/FB8-172 Reference Patch: facebook@b90e801 Reference Patch: facebook@ecef4b2 There are cases where it is always unacceptable for a client to be doing full table scans. To prevent this from happening, add a new variable optimizer_full_scan. When it is turned off, it will return a new error code ER_FULL_SCAN_DISABLED. For best results, use with optimizer_force_index_for_range. Currently, it does not fallback to alternative plans because we check at the end of query planning. EXPLAIN queries with derived tables do not populate select_options in the JOIN structure properly. This means that we could error if we tried to run an explain on a query with derived tables. Instead of reading from the JOIN struct, read from the LEX struct on the THD, as this is where the flag is original set on during query parsing. This bug also means that in upstream, we increment some status variables tracking full table scans despite the fact that only an explain statement was done. This seems to have been fixed in 8.0 though. Pull Request resolved: facebook#970 Reviewed By: lloyd Differential Revision: D14567846 Pulled By: lth
inikep
pushed a commit
to inikep/percona-server
that referenced
this pull request
Apr 17, 2024
…percona#970) Summary: Jira issue: https://jira.percona.com/browse/FB8-172 Reference Patch: facebook/mysql-5.6@b90e801 Reference Patch: facebook/mysql-5.6@ecef4b2 There are cases where it is always unacceptable for a client to be doing full table scans. To prevent this from happening, add a new variable optimizer_full_scan. When it is turned off, it will return a new error code ER_FULL_SCAN_DISABLED. For best results, use with optimizer_force_index_for_range. Currently, it does not fallback to alternative plans because we check at the end of query planning. EXPLAIN queries with derived tables do not populate select_options in the JOIN structure properly. This means that we could error if we tried to run an explain on a query with derived tables. Instead of reading from the JOIN struct, read from the LEX struct on the THD, as this is where the flag is original set on during query parsing. This bug also means that in upstream, we increment some status variables tracking full table scans despite the fact that only an explain statement was done. This seems to have been fixed in 8.0 though. Pull Request resolved: facebook/mysql-5.6#970 Reviewed By: lloyd Differential Revision: D14567846 Pulled By: lth
inikep
pushed a commit
to inikep/mysql-5.6
that referenced
this pull request
Apr 23, 2024
facebook#970) Summary: Jira issue: https://jira.percona.com/browse/FB8-172 Reference Patch: facebook@b90e801 Reference Patch: facebook@ecef4b2 There are cases where it is always unacceptable for a client to be doing full table scans. To prevent this from happening, add a new variable optimizer_full_scan. When it is turned off, it will return a new error code ER_FULL_SCAN_DISABLED. For best results, use with optimizer_force_index_for_range. Currently, it does not fallback to alternative plans because we check at the end of query planning. EXPLAIN queries with derived tables do not populate select_options in the JOIN structure properly. This means that we could error if we tried to run an explain on a query with derived tables. Instead of reading from the JOIN struct, read from the LEX struct on the THD, as this is where the flag is original set on during query parsing. This bug also means that in upstream, we increment some status variables tracking full table scans despite the fact that only an explain statement was done. This seems to have been fixed in 8.0 though. Pull Request resolved: facebook#970 Reviewed By: lloyd Differential Revision: D14567846 Pulled By: lth
inikep
pushed a commit
to inikep/mysql-5.6
that referenced
this pull request
Apr 23, 2024
facebook#970) Summary: Jira issue: https://jira.percona.com/browse/FB8-172 Reference Patch: facebook@b90e801 Reference Patch: facebook@ecef4b2 There are cases where it is always unacceptable for a client to be doing full table scans. To prevent this from happening, add a new variable optimizer_full_scan. When it is turned off, it will return a new error code ER_FULL_SCAN_DISABLED. For best results, use with optimizer_force_index_for_range. Currently, it does not fallback to alternative plans because we check at the end of query planning. EXPLAIN queries with derived tables do not populate select_options in the JOIN structure properly. This means that we could error if we tried to run an explain on a query with derived tables. Instead of reading from the JOIN struct, read from the LEX struct on the THD, as this is where the flag is original set on during query parsing. This bug also means that in upstream, we increment some status variables tracking full table scans despite the fact that only an explain statement was done. This seems to have been fixed in 8.0 though. Pull Request resolved: facebook#970 Reviewed By: lloyd Differential Revision: D14567846 Pulled By: lth
inikep
pushed a commit
to inikep/mysql-5.6
that referenced
this pull request
Apr 25, 2024
facebook#970) Summary: Jira issue: https://jira.percona.com/browse/FB8-172 Reference Patch: facebook@b90e801 Reference Patch: facebook@ecef4b2 There are cases where it is always unacceptable for a client to be doing full table scans. To prevent this from happening, add a new variable optimizer_full_scan. When it is turned off, it will return a new error code ER_FULL_SCAN_DISABLED. For best results, use with optimizer_force_index_for_range. Currently, it does not fallback to alternative plans because we check at the end of query planning. EXPLAIN queries with derived tables do not populate select_options in the JOIN structure properly. This means that we could error if we tried to run an explain on a query with derived tables. Instead of reading from the JOIN struct, read from the LEX struct on the THD, as this is where the flag is original set on during query parsing. This bug also means that in upstream, we increment some status variables tracking full table scans despite the fact that only an explain statement was done. This seems to have been fixed in 8.0 though. Pull Request resolved: facebook#970 Reviewed By: lloyd Differential Revision: D14567846 Pulled By: lth
inikep
pushed a commit
to inikep/mysql-5.6
that referenced
this pull request
May 7, 2024
facebook#970) Summary: Jira issue: https://jira.percona.com/browse/FB8-172 Reference Patch: facebook@b90e801 Reference Patch: facebook@ecef4b2 There are cases where it is always unacceptable for a client to be doing full table scans. To prevent this from happening, add a new variable optimizer_full_scan. When it is turned off, it will return a new error code ER_FULL_SCAN_DISABLED. For best results, use with optimizer_force_index_for_range. Currently, it does not fallback to alternative plans because we check at the end of query planning. EXPLAIN queries with derived tables do not populate select_options in the JOIN structure properly. This means that we could error if we tried to run an explain on a query with derived tables. Instead of reading from the JOIN struct, read from the LEX struct on the THD, as this is where the flag is original set on during query parsing. This bug also means that in upstream, we increment some status variables tracking full table scans despite the fact that only an explain statement was done. This seems to have been fixed in 8.0 though. Pull Request resolved: facebook#970 Reviewed By: lloyd Differential Revision: D14567846 Pulled By: lth
inikep
pushed a commit
to inikep/mysql-5.6
that referenced
this pull request
May 8, 2024
facebook#970) Summary: Jira issue: https://jira.percona.com/browse/FB8-172 Reference Patch: facebook@b90e801 Reference Patch: facebook@ecef4b2 There are cases where it is always unacceptable for a client to be doing full table scans. To prevent this from happening, add a new variable optimizer_full_scan. When it is turned off, it will return a new error code ER_FULL_SCAN_DISABLED. For best results, use with optimizer_force_index_for_range. Currently, it does not fallback to alternative plans because we check at the end of query planning. EXPLAIN queries with derived tables do not populate select_options in the JOIN structure properly. This means that we could error if we tried to run an explain on a query with derived tables. Instead of reading from the JOIN struct, read from the LEX struct on the THD, as this is where the flag is original set on during query parsing. This bug also means that in upstream, we increment some status variables tracking full table scans despite the fact that only an explain statement was done. This seems to have been fixed in 8.0 though. Pull Request resolved: facebook#970 Reviewed By: lloyd Differential Revision: D14567846 Pulled By: lth
inikep
pushed a commit
to inikep/mysql-5.6
that referenced
this pull request
May 9, 2024
facebook#970) Summary: Jira issue: https://jira.percona.com/browse/FB8-172 Reference Patch: facebook@b90e801 Reference Patch: facebook@ecef4b2 There are cases where it is always unacceptable for a client to be doing full table scans. To prevent this from happening, add a new variable optimizer_full_scan. When it is turned off, it will return a new error code ER_FULL_SCAN_DISABLED. For best results, use with optimizer_force_index_for_range. Currently, it does not fallback to alternative plans because we check at the end of query planning. EXPLAIN queries with derived tables do not populate select_options in the JOIN structure properly. This means that we could error if we tried to run an explain on a query with derived tables. Instead of reading from the JOIN struct, read from the LEX struct on the THD, as this is where the flag is original set on during query parsing. This bug also means that in upstream, we increment some status variables tracking full table scans despite the fact that only an explain statement was done. This seems to have been fixed in 8.0 though. Pull Request resolved: facebook#970 Reviewed By: lloyd Differential Revision: D14567846 Pulled By: lth
inikep
pushed a commit
to inikep/mysql-5.6
that referenced
this pull request
May 10, 2024
facebook#970) Summary: Jira issue: https://jira.percona.com/browse/FB8-172 Reference Patch: facebook@b90e801 Reference Patch: facebook@ecef4b2 There are cases where it is always unacceptable for a client to be doing full table scans. To prevent this from happening, add a new variable optimizer_full_scan. When it is turned off, it will return a new error code ER_FULL_SCAN_DISABLED. For best results, use with optimizer_force_index_for_range. Currently, it does not fallback to alternative plans because we check at the end of query planning. EXPLAIN queries with derived tables do not populate select_options in the JOIN structure properly. This means that we could error if we tried to run an explain on a query with derived tables. Instead of reading from the JOIN struct, read from the LEX struct on the THD, as this is where the flag is original set on during query parsing. This bug also means that in upstream, we increment some status variables tracking full table scans despite the fact that only an explain statement was done. This seems to have been fixed in 8.0 though. Pull Request resolved: facebook#970 Reviewed By: lloyd Differential Revision: D14567846 Pulled By: lth
inikep
pushed a commit
to inikep/mysql-5.6
that referenced
this pull request
May 13, 2024
facebook#970) Summary: Jira issue: https://jira.percona.com/browse/FB8-172 Reference Patch: facebook@b90e801 Reference Patch: facebook@ecef4b2 There are cases where it is always unacceptable for a client to be doing full table scans. To prevent this from happening, add a new variable optimizer_full_scan. When it is turned off, it will return a new error code ER_FULL_SCAN_DISABLED. For best results, use with optimizer_force_index_for_range. Currently, it does not fallback to alternative plans because we check at the end of query planning. EXPLAIN queries with derived tables do not populate select_options in the JOIN structure properly. This means that we could error if we tried to run an explain on a query with derived tables. Instead of reading from the JOIN struct, read from the LEX struct on the THD, as this is where the flag is original set on during query parsing. This bug also means that in upstream, we increment some status variables tracking full table scans despite the fact that only an explain statement was done. This seems to have been fixed in 8.0 though. Pull Request resolved: facebook#970 Reviewed By: lloyd Differential Revision: D14567846 Pulled By: lth
inikep
pushed a commit
to inikep/mysql-5.6
that referenced
this pull request
May 15, 2024
facebook#970) Summary: Jira issue: https://jira.percona.com/browse/FB8-172 Reference Patch: facebook@b90e801 Reference Patch: facebook@ecef4b2 There are cases where it is always unacceptable for a client to be doing full table scans. To prevent this from happening, add a new variable optimizer_full_scan. When it is turned off, it will return a new error code ER_FULL_SCAN_DISABLED. For best results, use with optimizer_force_index_for_range. Currently, it does not fallback to alternative plans because we check at the end of query planning. EXPLAIN queries with derived tables do not populate select_options in the JOIN structure properly. This means that we could error if we tried to run an explain on a query with derived tables. Instead of reading from the JOIN struct, read from the LEX struct on the THD, as this is where the flag is original set on during query parsing. This bug also means that in upstream, we increment some status variables tracking full table scans despite the fact that only an explain statement was done. This seems to have been fixed in 8.0 though. Pull Request resolved: facebook#970 Reviewed By: lloyd Differential Revision: D14567846 Pulled By: lth
inikep
pushed a commit
to inikep/mysql-5.6
that referenced
this pull request
May 16, 2024
facebook#970) Summary: Jira issue: https://jira.percona.com/browse/FB8-172 Reference Patch: facebook@b90e801 Reference Patch: facebook@ecef4b2 There are cases where it is always unacceptable for a client to be doing full table scans. To prevent this from happening, add a new variable optimizer_full_scan. When it is turned off, it will return a new error code ER_FULL_SCAN_DISABLED. For best results, use with optimizer_force_index_for_range. Currently, it does not fallback to alternative plans because we check at the end of query planning. EXPLAIN queries with derived tables do not populate select_options in the JOIN structure properly. This means that we could error if we tried to run an explain on a query with derived tables. Instead of reading from the JOIN struct, read from the LEX struct on the THD, as this is where the flag is original set on during query parsing. This bug also means that in upstream, we increment some status variables tracking full table scans despite the fact that only an explain statement was done. This seems to have been fixed in 8.0 though. Pull Request resolved: facebook#970 Reviewed By: lloyd Differential Revision: D14567846 Pulled By: lth
inikep
pushed a commit
to inikep/mysql-5.6
that referenced
this pull request
May 17, 2024
facebook#970) Summary: Jira issue: https://jira.percona.com/browse/FB8-172 Reference Patch: facebook@b90e801 Reference Patch: facebook@ecef4b2 There are cases where it is always unacceptable for a client to be doing full table scans. To prevent this from happening, add a new variable optimizer_full_scan. When it is turned off, it will return a new error code ER_FULL_SCAN_DISABLED. For best results, use with optimizer_force_index_for_range. Currently, it does not fallback to alternative plans because we check at the end of query planning. EXPLAIN queries with derived tables do not populate select_options in the JOIN structure properly. This means that we could error if we tried to run an explain on a query with derived tables. Instead of reading from the JOIN struct, read from the LEX struct on the THD, as this is where the flag is original set on during query parsing. This bug also means that in upstream, we increment some status variables tracking full table scans despite the fact that only an explain statement was done. This seems to have been fixed in 8.0 though. Pull Request resolved: facebook#970 Reviewed By: lloyd Differential Revision: D14567846 Pulled By: lth
inikep
pushed a commit
to inikep/mysql-5.6
that referenced
this pull request
May 17, 2024
facebook#970) Summary: Jira issue: https://jira.percona.com/browse/FB8-172 Reference Patch: facebook@b90e801 Reference Patch: facebook@ecef4b2 There are cases where it is always unacceptable for a client to be doing full table scans. To prevent this from happening, add a new variable optimizer_full_scan. When it is turned off, it will return a new error code ER_FULL_SCAN_DISABLED. For best results, use with optimizer_force_index_for_range. Currently, it does not fallback to alternative plans because we check at the end of query planning. EXPLAIN queries with derived tables do not populate select_options in the JOIN structure properly. This means that we could error if we tried to run an explain on a query with derived tables. Instead of reading from the JOIN struct, read from the LEX struct on the THD, as this is where the flag is original set on during query parsing. This bug also means that in upstream, we increment some status variables tracking full table scans despite the fact that only an explain statement was done. This seems to have been fixed in 8.0 though. Pull Request resolved: facebook#970 Reviewed By: lloyd Differential Revision: D14567846 Pulled By: lth
inikep
pushed a commit
to inikep/mysql-5.6
that referenced
this pull request
May 21, 2024
facebook#970) Summary: Jira issue: https://jira.percona.com/browse/FB8-172 Reference Patch: facebook@b90e801 Reference Patch: facebook@ecef4b2 There are cases where it is always unacceptable for a client to be doing full table scans. To prevent this from happening, add a new variable optimizer_full_scan. When it is turned off, it will return a new error code ER_FULL_SCAN_DISABLED. For best results, use with optimizer_force_index_for_range. Currently, it does not fallback to alternative plans because we check at the end of query planning. EXPLAIN queries with derived tables do not populate select_options in the JOIN structure properly. This means that we could error if we tried to run an explain on a query with derived tables. Instead of reading from the JOIN struct, read from the LEX struct on the THD, as this is where the flag is original set on during query parsing. This bug also means that in upstream, we increment some status variables tracking full table scans despite the fact that only an explain statement was done. This seems to have been fixed in 8.0 though. Pull Request resolved: facebook#970 Reviewed By: lloyd Differential Revision: D14567846 Pulled By: lth
inikep
pushed a commit
to inikep/mysql-5.6
that referenced
this pull request
May 21, 2024
facebook#970) Summary: Jira issue: https://jira.percona.com/browse/FB8-172 Reference Patch: facebook@b90e801 Reference Patch: facebook@ecef4b2 There are cases where it is always unacceptable for a client to be doing full table scans. To prevent this from happening, add a new variable optimizer_full_scan. When it is turned off, it will return a new error code ER_FULL_SCAN_DISABLED. For best results, use with optimizer_force_index_for_range. Currently, it does not fallback to alternative plans because we check at the end of query planning. EXPLAIN queries with derived tables do not populate select_options in the JOIN structure properly. This means that we could error if we tried to run an explain on a query with derived tables. Instead of reading from the JOIN struct, read from the LEX struct on the THD, as this is where the flag is original set on during query parsing. This bug also means that in upstream, we increment some status variables tracking full table scans despite the fact that only an explain statement was done. This seems to have been fixed in 8.0 though. Pull Request resolved: facebook#970 Reviewed By: lloyd Differential Revision: D14567846 Pulled By: lth
inikep
pushed a commit
to inikep/mysql-5.6
that referenced
this pull request
May 30, 2024
facebook#970) Summary: Jira issue: https://jira.percona.com/browse/FB8-172 Reference Patch: facebook@b90e801 Reference Patch: facebook@ecef4b2 There are cases where it is always unacceptable for a client to be doing full table scans. To prevent this from happening, add a new variable optimizer_full_scan. When it is turned off, it will return a new error code ER_FULL_SCAN_DISABLED. For best results, use with optimizer_force_index_for_range. Currently, it does not fallback to alternative plans because we check at the end of query planning. EXPLAIN queries with derived tables do not populate select_options in the JOIN structure properly. This means that we could error if we tried to run an explain on a query with derived tables. Instead of reading from the JOIN struct, read from the LEX struct on the THD, as this is where the flag is original set on during query parsing. This bug also means that in upstream, we increment some status variables tracking full table scans despite the fact that only an explain statement was done. This seems to have been fixed in 8.0 though. Pull Request resolved: facebook#970 Reviewed By: lloyd Differential Revision: D14567846 Pulled By: lth
inikep
pushed a commit
to inikep/mysql-5.6
that referenced
this pull request
Jun 14, 2024
facebook#970) Summary: Jira issue: https://jira.percona.com/browse/FB8-172 Reference Patch: facebook@b90e801 Reference Patch: facebook@ecef4b2 There are cases where it is always unacceptable for a client to be doing full table scans. To prevent this from happening, add a new variable optimizer_full_scan. When it is turned off, it will return a new error code ER_FULL_SCAN_DISABLED. For best results, use with optimizer_force_index_for_range. Currently, it does not fallback to alternative plans because we check at the end of query planning. EXPLAIN queries with derived tables do not populate select_options in the JOIN structure properly. This means that we could error if we tried to run an explain on a query with derived tables. Instead of reading from the JOIN struct, read from the LEX struct on the THD, as this is where the flag is original set on during query parsing. This bug also means that in upstream, we increment some status variables tracking full table scans despite the fact that only an explain statement was done. This seems to have been fixed in 8.0 though. Pull Request resolved: facebook#970 Reviewed By: lloyd Differential Revision: D14567846 Pulled By: lth
inikep
pushed a commit
to inikep/mysql-5.6
that referenced
this pull request
Jun 19, 2024
facebook#970) Summary: Jira issue: https://jira.percona.com/browse/FB8-172 Reference Patch: facebook@b90e801 Reference Patch: facebook@ecef4b2 There are cases where it is always unacceptable for a client to be doing full table scans. To prevent this from happening, add a new variable optimizer_full_scan. When it is turned off, it will return a new error code ER_FULL_SCAN_DISABLED. For best results, use with optimizer_force_index_for_range. Currently, it does not fallback to alternative plans because we check at the end of query planning. EXPLAIN queries with derived tables do not populate select_options in the JOIN structure properly. This means that we could error if we tried to run an explain on a query with derived tables. Instead of reading from the JOIN struct, read from the LEX struct on the THD, as this is where the flag is original set on during query parsing. This bug also means that in upstream, we increment some status variables tracking full table scans despite the fact that only an explain statement was done. This seems to have been fixed in 8.0 though. Pull Request resolved: facebook#970 Reviewed By: lloyd Differential Revision: D14567846 Pulled By: lth
inikep
pushed a commit
to inikep/mysql-5.6
that referenced
this pull request
Jun 20, 2024
facebook#970) Summary: Jira issue: https://jira.percona.com/browse/FB8-172 Reference Patch: facebook@b90e801 Reference Patch: facebook@ecef4b2 There are cases where it is always unacceptable for a client to be doing full table scans. To prevent this from happening, add a new variable optimizer_full_scan. When it is turned off, it will return a new error code ER_FULL_SCAN_DISABLED. For best results, use with optimizer_force_index_for_range. Currently, it does not fallback to alternative plans because we check at the end of query planning. EXPLAIN queries with derived tables do not populate select_options in the JOIN structure properly. This means that we could error if we tried to run an explain on a query with derived tables. Instead of reading from the JOIN struct, read from the LEX struct on the THD, as this is where the flag is original set on during query parsing. This bug also means that in upstream, we increment some status variables tracking full table scans despite the fact that only an explain statement was done. This seems to have been fixed in 8.0 though. Pull Request resolved: facebook#970 Reviewed By: lloyd Differential Revision: D14567846 Pulled By: lth
inikep
pushed a commit
to inikep/mysql-5.6
that referenced
this pull request
Jun 21, 2024
facebook#970) Summary: Jira issue: https://jira.percona.com/browse/FB8-172 Reference Patch: facebook@b90e801 Reference Patch: facebook@ecef4b2 There are cases where it is always unacceptable for a client to be doing full table scans. To prevent this from happening, add a new variable optimizer_full_scan. When it is turned off, it will return a new error code ER_FULL_SCAN_DISABLED. For best results, use with optimizer_force_index_for_range. Currently, it does not fallback to alternative plans because we check at the end of query planning. EXPLAIN queries with derived tables do not populate select_options in the JOIN structure properly. This means that we could error if we tried to run an explain on a query with derived tables. Instead of reading from the JOIN struct, read from the LEX struct on the THD, as this is where the flag is original set on during query parsing. This bug also means that in upstream, we increment some status variables tracking full table scans despite the fact that only an explain statement was done. This seems to have been fixed in 8.0 though. Pull Request resolved: facebook#970 Reviewed By: lloyd Differential Revision: D14567846 Pulled By: lth
inikep
pushed a commit
to inikep/mysql-5.6
that referenced
this pull request
Jun 25, 2024
facebook#970) Summary: Jira issue: https://jira.percona.com/browse/FB8-172 Reference Patch: facebook@b90e801 Reference Patch: facebook@ecef4b2 There are cases where it is always unacceptable for a client to be doing full table scans. To prevent this from happening, add a new variable optimizer_full_scan. When it is turned off, it will return a new error code ER_FULL_SCAN_DISABLED. For best results, use with optimizer_force_index_for_range. Currently, it does not fallback to alternative plans because we check at the end of query planning. EXPLAIN queries with derived tables do not populate select_options in the JOIN structure properly. This means that we could error if we tried to run an explain on a query with derived tables. Instead of reading from the JOIN struct, read from the LEX struct on the THD, as this is where the flag is original set on during query parsing. This bug also means that in upstream, we increment some status variables tracking full table scans despite the fact that only an explain statement was done. This seems to have been fixed in 8.0 though. Pull Request resolved: facebook#970 Reviewed By: lloyd Differential Revision: D14567846 Pulled By: lth
inikep
pushed a commit
to inikep/mysql-5.6
that referenced
this pull request
Jul 2, 2024
facebook#970) Summary: Jira issue: https://jira.percona.com/browse/FB8-172 Reference Patch: facebook@b90e801 Reference Patch: facebook@ecef4b2 There are cases where it is always unacceptable for a client to be doing full table scans. To prevent this from happening, add a new variable optimizer_full_scan. When it is turned off, it will return a new error code ER_FULL_SCAN_DISABLED. For best results, use with optimizer_force_index_for_range. Currently, it does not fallback to alternative plans because we check at the end of query planning. EXPLAIN queries with derived tables do not populate select_options in the JOIN structure properly. This means that we could error if we tried to run an explain on a query with derived tables. Instead of reading from the JOIN struct, read from the LEX struct on the THD, as this is where the flag is original set on during query parsing. This bug also means that in upstream, we increment some status variables tracking full table scans despite the fact that only an explain statement was done. This seems to have been fixed in 8.0 though. Pull Request resolved: facebook#970 Reviewed By: lloyd Differential Revision: D14567846 Pulled By: lth
inikep
pushed a commit
to inikep/mysql-5.6
that referenced
this pull request
Jul 19, 2024
facebook#970) Summary: Jira issue: https://jira.percona.com/browse/FB8-172 Reference Patch: facebook@b90e801 Reference Patch: facebook@ecef4b2 There are cases where it is always unacceptable for a client to be doing full table scans. To prevent this from happening, add a new variable optimizer_full_scan. When it is turned off, it will return a new error code ER_FULL_SCAN_DISABLED. For best results, use with optimizer_force_index_for_range. Currently, it does not fallback to alternative plans because we check at the end of query planning. EXPLAIN queries with derived tables do not populate select_options in the JOIN structure properly. This means that we could error if we tried to run an explain on a query with derived tables. Instead of reading from the JOIN struct, read from the LEX struct on the THD, as this is where the flag is original set on during query parsing. This bug also means that in upstream, we increment some status variables tracking full table scans despite the fact that only an explain statement was done. This seems to have been fixed in 8.0 though. Pull Request resolved: facebook#970 Reviewed By: lloyd Differential Revision: D14567846 Pulled By: lth
inikep
pushed a commit
to inikep/mysql-5.6
that referenced
this pull request
Jul 19, 2024
facebook#970) Summary: Jira issue: https://jira.percona.com/browse/FB8-172 Reference Patch: facebook@b90e801 Reference Patch: facebook@ecef4b2 There are cases where it is always unacceptable for a client to be doing full table scans. To prevent this from happening, add a new variable optimizer_full_scan. When it is turned off, it will return a new error code ER_FULL_SCAN_DISABLED. For best results, use with optimizer_force_index_for_range. Currently, it does not fallback to alternative plans because we check at the end of query planning. EXPLAIN queries with derived tables do not populate select_options in the JOIN structure properly. This means that we could error if we tried to run an explain on a query with derived tables. Instead of reading from the JOIN struct, read from the LEX struct on the THD, as this is where the flag is original set on during query parsing. This bug also means that in upstream, we increment some status variables tracking full table scans despite the fact that only an explain statement was done. This seems to have been fixed in 8.0 though. Pull Request resolved: facebook#970 Reviewed By: lloyd Differential Revision: D14567846 Pulled By: lth
inikep
pushed a commit
to inikep/mysql-5.6
that referenced
this pull request
Jul 31, 2024
facebook#970) Summary: Jira issue: https://jira.percona.com/browse/FB8-172 Reference Patch: facebook@b90e801 Reference Patch: facebook@ecef4b2 There are cases where it is always unacceptable for a client to be doing full table scans. To prevent this from happening, add a new variable optimizer_full_scan. When it is turned off, it will return a new error code ER_FULL_SCAN_DISABLED. For best results, use with optimizer_force_index_for_range. Currently, it does not fallback to alternative plans because we check at the end of query planning. EXPLAIN queries with derived tables do not populate select_options in the JOIN structure properly. This means that we could error if we tried to run an explain on a query with derived tables. Instead of reading from the JOIN struct, read from the LEX struct on the THD, as this is where the flag is original set on during query parsing. This bug also means that in upstream, we increment some status variables tracking full table scans despite the fact that only an explain statement was done. This seems to have been fixed in 8.0 though. Pull Request resolved: facebook#970 Reviewed By: lloyd Differential Revision: D14567846 Pulled By: lth
inikep
pushed a commit
to inikep/mysql-5.6
that referenced
this pull request
Aug 2, 2024
facebook#970) Summary: Jira issue: https://jira.percona.com/browse/FB8-172 Reference Patch: facebook@b90e801 Reference Patch: facebook@ecef4b2 There are cases where it is always unacceptable for a client to be doing full table scans. To prevent this from happening, add a new variable optimizer_full_scan. When it is turned off, it will return a new error code ER_FULL_SCAN_DISABLED. For best results, use with optimizer_force_index_for_range. Currently, it does not fallback to alternative plans because we check at the end of query planning. EXPLAIN queries with derived tables do not populate select_options in the JOIN structure properly. This means that we could error if we tried to run an explain on a query with derived tables. Instead of reading from the JOIN struct, read from the LEX struct on the THD, as this is where the flag is original set on during query parsing. This bug also means that in upstream, we increment some status variables tracking full table scans despite the fact that only an explain statement was done. This seems to have been fixed in 8.0 though. Pull Request resolved: facebook#970 Reviewed By: lloyd Differential Revision: D14567846 Pulled By: lth
inikep
pushed a commit
to inikep/mysql-5.6
that referenced
this pull request
Aug 6, 2024
facebook#970) Summary: Jira issue: https://jira.percona.com/browse/FB8-172 Reference Patch: facebook@b90e801 Reference Patch: facebook@ecef4b2 There are cases where it is always unacceptable for a client to be doing full table scans. To prevent this from happening, add a new variable optimizer_full_scan. When it is turned off, it will return a new error code ER_FULL_SCAN_DISABLED. For best results, use with optimizer_force_index_for_range. Currently, it does not fallback to alternative plans because we check at the end of query planning. EXPLAIN queries with derived tables do not populate select_options in the JOIN structure properly. This means that we could error if we tried to run an explain on a query with derived tables. Instead of reading from the JOIN struct, read from the LEX struct on the THD, as this is where the flag is original set on during query parsing. This bug also means that in upstream, we increment some status variables tracking full table scans despite the fact that only an explain statement was done. This seems to have been fixed in 8.0 though. Pull Request resolved: facebook#970 Reviewed By: lloyd Differential Revision: D14567846 Pulled By: lth
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Jira issue: https://jira.percona.com/browse/FB8-172
Reference Patch: b90e801
Reference Patch: ecef4b2
There are cases where it is always unacceptable for a client to be doing full table scans. To prevent this from happening, add a new variable optimizer_full_scan. When it is turned off, it will return a new error code ER_FULL_SCAN_DISABLED.
For best results, use with optimizer_force_index_for_range. Currently, it does not fallback to alternative plans because we check at the end of query planning.
EXPLAIN queries with derived tables do not populate select_options in the JOIN structure properly. This means that we could error if we tried to run an explain on a query with derived tables.
Instead of reading from the JOIN struct, read from the LEX struct on the THD, as this is where the flag is original set on during query parsing.
This bug also means that in upstream, we increment some status variables tracking full table scans despite the fact that only an explain statement was done. This seems to have been fixed in 8.0 though.
TODO: Because of conflicts I removed changes in
mysql-test/t/all_persisted_variables.test. This test has to be modified atlet $total_persistent_vars=XXX;(+1 increase) and it should be re-recorded.