Details
-
New Feature
-
Status: Open (View Workflow)
-
Major
-
Resolution: Unresolved
-
Server 12.1 dev sprint
Description
Add a new-style hint to control Rowid Filters.
/* +ROWID_FILTER( [table_name [index_name [ ...] ]]) */
|
/* +NO_ROWID_FILTER([table_name [index_name [ ... ] ]] ) */ |
Hint applicability
Like NO_RANGE_OPTIMIZATION or MRR, the hint can apply to
- Query block - NO_ROWID_FILTER()
- Table - NO_ROWID_FILTER(table_name)
- Specific index(es) - NO_ROWID_FILTER(table_name index1 index2 ...
Semantics
Semantics of NO_ROWID_FILTER
Do not consider Rowid Filter for the scope of the hint (all tables in the query block, specific table, specific index(es)).
Semantics of ROWID_FILTER
This should do something like "force use of ROWID_FILTER for the table.index it targets" but there are some issues:
Possible semantics #1
At query block or table level it makes sense to have the meaning just "enable use of ROWID_FILTER". Assuming it is disabled globally.
Possible semantics #2
At index level, it would be nice to force use of indexes regardless of the costs.
That is,
SELECT /*+ ROWID_FILTER(t1 idx1) */ |
would force the use of Rowid Filter made from t1.idx1 if the picked plan allows it, regardless of the costs.
A problem?
Suppose we have implemented the logic:
ROWID_FILTER(t1 idx1) makes the optimizer to use RowidFilter(idx1) if the access method to t1 allows it.
Then we run some query Q without any hints.
Suppose the optimizer's choice is to use index idx2 for accessing table t1.
Then we add the ROWID_FILTER(t1 idx1) to the Q and run it.
When the optimizer looks for access method to t1, it picks idx2 and adds rowid filter(t1) .
This makes the const higher than just using idx2.
Use of idx2+RowidFilter(idx1) may become more expensive than e.g. full table scan.
Or the join order may change.
That is, the effect of the ROWID FILTER(t1 idx1) hint may be that some totally different plan will be used.
...
TODO:
- When creating potential Rowid filters, only consider the specified indexes.
- the ROWID_FILTER hint doesn't affect the choice of access method.
If the optimizer picks an index for which this rowid filter can be applied, good. If not, not our problem.
- When considering whether to use the rowid filter together with an index,
make a cost-based choice between specified filters.
There are some ideas about specifying the buffer size available for the rowid filter but they are outside of the scope of this MDEV.
Attachments
Issue Links
- split from
-
MDEV-33281 Implement optimizer hints like in MySQL 8
-
- In Progress
-
Activity
Field | Original Value | New Value |
---|---|---|
Description |
Add a new-style hint to control rowid filters.
{code:sql} /* +ROWID_FILTER(table_name [index_name, ...]) */ /* +NO_ROWID_FILTER(table_name [index_name]) */ {code} h2. The meaning of the hint NO_ROWID_FILTER is easy - do not consider rowid filters on the specified indexes. (If just table is specified, don't construct any for the table) ROWID_FILTER means do construct rowid filters on the specified table. - When creating potential rowid filters, only consider the specified indexes. - the ROWID_FILTER hint doesn't affect the choice of access method. If the optimizer picks an index for which this rowid filter can be applied, good. If not, not our problem. - When considering whether to use the rowid filter together with an index, make a cost-based choice between specified filters. There are some ideas about specifying the buffer size available for the rowid filter but they are outside of the scope of this MDEV. |
Add a new-style hint to control Rowid Filters.
{code:sql} /* +ROWID_FILTER( [table_name [index_name [ ...] ]]) */ /* +NO_ROWID_FILTER([table_name [index_name [ ... ] ]] ) */ {code} h2. Hint applicability Like {{NO_RANGE_OPTIMIZATION}} or {{MRR}}, the hint can apply to * Query block - {{NO_ROWID_FILTER()}} * Table - {{NO_ROWID_FILTER(table_name)}} * Specific index(es) - {{NO_ROWID_FILTER(table_name index1 index2 ...}} h2. Semantics h3. Semantics of NO_ROWID_FILTER Do not consider Rowid Filter for the scope of the hint (all tables in the query block, specific table, specific index(es)). h2. Semantics of ROWID_FILTER In short: Force use of ROWID_FILTER for the {{table.index}} it targets (?) TODO: - When creating potential rowid filters, only consider the specified indexes. - the ROWID_FILTER hint doesn't affect the choice of access method. If the optimizer picks an index for which this rowid filter can be applied, good. If not, not our problem. - When considering whether to use the rowid filter together with an index, make a cost-based choice between specified filters. There are some ideas about specifying the buffer size available for the rowid filter but they are outside of the scope of this MDEV. |
Description |
Add a new-style hint to control Rowid Filters.
{code:sql} /* +ROWID_FILTER( [table_name [index_name [ ...] ]]) */ /* +NO_ROWID_FILTER([table_name [index_name [ ... ] ]] ) */ {code} h2. Hint applicability Like {{NO_RANGE_OPTIMIZATION}} or {{MRR}}, the hint can apply to * Query block - {{NO_ROWID_FILTER()}} * Table - {{NO_ROWID_FILTER(table_name)}} * Specific index(es) - {{NO_ROWID_FILTER(table_name index1 index2 ...}} h2. Semantics h3. Semantics of NO_ROWID_FILTER Do not consider Rowid Filter for the scope of the hint (all tables in the query block, specific table, specific index(es)). h2. Semantics of ROWID_FILTER In short: Force use of ROWID_FILTER for the {{table.index}} it targets (?) TODO: - When creating potential rowid filters, only consider the specified indexes. - the ROWID_FILTER hint doesn't affect the choice of access method. If the optimizer picks an index for which this rowid filter can be applied, good. If not, not our problem. - When considering whether to use the rowid filter together with an index, make a cost-based choice between specified filters. There are some ideas about specifying the buffer size available for the rowid filter but they are outside of the scope of this MDEV. |
Add a new-style hint to control Rowid Filters.
{code:sql} /* +ROWID_FILTER( [table_name [index_name [ ...] ]]) */ /* +NO_ROWID_FILTER([table_name [index_name [ ... ] ]] ) */ {code} h2. Hint applicability Like {{NO_RANGE_OPTIMIZATION}} or {{MRR}}, the hint can apply to * Query block - {{NO_ROWID_FILTER()}} * Table - {{NO_ROWID_FILTER(table_name)}} * Specific index(es) - {{NO_ROWID_FILTER(table_name index1 index2 ...}} h2. Semantics h3. Semantics of NO_ROWID_FILTER Do not consider Rowid Filter for the scope of the hint (all tables in the query block, specific table, specific index(es)). h2. Semantics of ROWID_FILTER In short: Force use of ROWID_FILTER for the {{table.index}} it targets (?) h3. Possible semantics #1 At query block or table level it makes sense to have the meaning just "enable use of ROWID_FILTER". Assuming it is disabled globally. h3. Possible semantics #2 At index level, it would be nice to force use of indexes regardless of the costs. That is, {code:sql} SELECT /* +ROWID_FILTER(t1 idx1) */ {code} would force the use of Rowid Filter made from t1.idx1 if the picked plan allows it, regardless of the costs. h2. ... TODO: - When creating potential Rowid filters, only consider the specified indexes. - the ROWID_FILTER hint doesn't affect the choice of access method. If the optimizer picks an index for which this rowid filter can be applied, good. If not, not our problem. - When considering whether to use the rowid filter together with an index, make a cost-based choice between specified filters. There are some ideas about specifying the buffer size available for the rowid filter but they are outside of the scope of this MDEV. |
Link | This issue relates to MDEV-33281 [ MDEV-33281 ] |
Description |
Add a new-style hint to control Rowid Filters.
{code:sql} /* +ROWID_FILTER( [table_name [index_name [ ...] ]]) */ /* +NO_ROWID_FILTER([table_name [index_name [ ... ] ]] ) */ {code} h2. Hint applicability Like {{NO_RANGE_OPTIMIZATION}} or {{MRR}}, the hint can apply to * Query block - {{NO_ROWID_FILTER()}} * Table - {{NO_ROWID_FILTER(table_name)}} * Specific index(es) - {{NO_ROWID_FILTER(table_name index1 index2 ...}} h2. Semantics h3. Semantics of NO_ROWID_FILTER Do not consider Rowid Filter for the scope of the hint (all tables in the query block, specific table, specific index(es)). h2. Semantics of ROWID_FILTER In short: Force use of ROWID_FILTER for the {{table.index}} it targets (?) h3. Possible semantics #1 At query block or table level it makes sense to have the meaning just "enable use of ROWID_FILTER". Assuming it is disabled globally. h3. Possible semantics #2 At index level, it would be nice to force use of indexes regardless of the costs. That is, {code:sql} SELECT /* +ROWID_FILTER(t1 idx1) */ {code} would force the use of Rowid Filter made from t1.idx1 if the picked plan allows it, regardless of the costs. h2. ... TODO: - When creating potential Rowid filters, only consider the specified indexes. - the ROWID_FILTER hint doesn't affect the choice of access method. If the optimizer picks an index for which this rowid filter can be applied, good. If not, not our problem. - When considering whether to use the rowid filter together with an index, make a cost-based choice between specified filters. There are some ideas about specifying the buffer size available for the rowid filter but they are outside of the scope of this MDEV. |
Add a new-style hint to control Rowid Filters.
{code:sql} /* +ROWID_FILTER( [table_name [index_name [ ...] ]]) */ /* +NO_ROWID_FILTER([table_name [index_name [ ... ] ]] ) */ {code} h2. Hint applicability Like {{NO_RANGE_OPTIMIZATION}} or {{MRR}}, the hint can apply to * Query block - {{NO_ROWID_FILTER()}} * Table - {{NO_ROWID_FILTER(table_name)}} * Specific index(es) - {{NO_ROWID_FILTER(table_name index1 index2 ...}} h2. Semantics h3. Semantics of NO_ROWID_FILTER Do not consider Rowid Filter for the scope of the hint (all tables in the query block, specific table, specific index(es)). h2. Semantics of ROWID_FILTER In short: Force use of ROWID_FILTER for the {{table.index}} it targets (?) h3. Possible semantics #1 At query block or table level it makes sense to have the meaning just "enable use of ROWID_FILTER". Assuming it is disabled globally. h3. Possible semantics #2 At index level, it would be nice to force use of indexes regardless of the costs. That is, {code:sql} SELECT /* +ROWID_FILTER(t1 idx1) */ {code} would force the use of Rowid Filter made from t1.idx1 if the picked plan allows it, regardless of the costs. h3. A problem? Suppose we have implemented the logic: {quote} {{+ROWID_FILTER(t1 idx1)}} makes the optimizer to use RowidFilter(idx1) if the access method to t1 allows it. {code} Consider a query without the hint. Suppose the optimizer's choice is to use index idx2 for accessing table t1. h2. ... TODO: - When creating potential Rowid filters, only consider the specified indexes. - the ROWID_FILTER hint doesn't affect the choice of access method. If the optimizer picks an index for which this rowid filter can be applied, good. If not, not our problem. - When considering whether to use the rowid filter together with an index, make a cost-based choice between specified filters. There are some ideas about specifying the buffer size available for the rowid filter but they are outside of the scope of this MDEV. |
Description |
Add a new-style hint to control Rowid Filters.
{code:sql} /* +ROWID_FILTER( [table_name [index_name [ ...] ]]) */ /* +NO_ROWID_FILTER([table_name [index_name [ ... ] ]] ) */ {code} h2. Hint applicability Like {{NO_RANGE_OPTIMIZATION}} or {{MRR}}, the hint can apply to * Query block - {{NO_ROWID_FILTER()}} * Table - {{NO_ROWID_FILTER(table_name)}} * Specific index(es) - {{NO_ROWID_FILTER(table_name index1 index2 ...}} h2. Semantics h3. Semantics of NO_ROWID_FILTER Do not consider Rowid Filter for the scope of the hint (all tables in the query block, specific table, specific index(es)). h2. Semantics of ROWID_FILTER In short: Force use of ROWID_FILTER for the {{table.index}} it targets (?) h3. Possible semantics #1 At query block or table level it makes sense to have the meaning just "enable use of ROWID_FILTER". Assuming it is disabled globally. h3. Possible semantics #2 At index level, it would be nice to force use of indexes regardless of the costs. That is, {code:sql} SELECT /* +ROWID_FILTER(t1 idx1) */ {code} would force the use of Rowid Filter made from t1.idx1 if the picked plan allows it, regardless of the costs. h3. A problem? Suppose we have implemented the logic: {quote} {{+ROWID_FILTER(t1 idx1)}} makes the optimizer to use RowidFilter(idx1) if the access method to t1 allows it. {code} Consider a query without the hint. Suppose the optimizer's choice is to use index idx2 for accessing table t1. h2. ... TODO: - When creating potential Rowid filters, only consider the specified indexes. - the ROWID_FILTER hint doesn't affect the choice of access method. If the optimizer picks an index for which this rowid filter can be applied, good. If not, not our problem. - When considering whether to use the rowid filter together with an index, make a cost-based choice between specified filters. There are some ideas about specifying the buffer size available for the rowid filter but they are outside of the scope of this MDEV. |
Add a new-style hint to control Rowid Filters.
{code:sql} /* +ROWID_FILTER( [table_name [index_name [ ...] ]]) */ /* +NO_ROWID_FILTER([table_name [index_name [ ... ] ]] ) */ {code} h2. Hint applicability Like {{NO_RANGE_OPTIMIZATION}} or {{MRR}}, the hint can apply to * Query block - {{NO_ROWID_FILTER()}} * Table - {{NO_ROWID_FILTER(table_name)}} * Specific index(es) - {{NO_ROWID_FILTER(table_name index1 index2 ...}} h2. Semantics h3. Semantics of NO_ROWID_FILTER Do not consider Rowid Filter for the scope of the hint (all tables in the query block, specific table, specific index(es)). h2. Semantics of ROWID_FILTER In short: Force use of ROWID_FILTER for the {{table.index}} it targets (?) h3. Possible semantics #1 At query block or table level it makes sense to have the meaning just "enable use of ROWID_FILTER". Assuming it is disabled globally. h3. Possible semantics #2 At index level, it would be nice to force use of indexes regardless of the costs. That is, {code:sql} SELECT /*+ ROWID_FILTER(t1 idx1) */ {code} would force the use of Rowid Filter made from t1.idx1 if the picked plan allows it, regardless of the costs. h3. A problem? Suppose we have implemented the logic: {quote} {{ROWID_FILTER(t1 idx1)}} makes the optimizer to use RowidFilter(idx1) if the access method to t1 allows it. {code} Then we run some query Q without any hints. Suppose the optimizer's choice is to use index idx2 for accessing table t1. Then we add the {{ROWID_FILTER(t1 idx1)}} to the Q and run it. When the optimizer looks for access method to t1, it picks idx2 and adds rowid filter(t1) . This makes the const higher than just using idx2. Use of {{idx2+RowidFilter(idx1)}} may become more expensive than e.g. full table scan. Or the join order may change. That is, the effect of the {{ROWID FILTER(t1 idx1)}} hint may be that some totally different plan will be used. h2. ... TODO: - When creating potential Rowid filters, only consider the specified indexes. - the ROWID_FILTER hint doesn't affect the choice of access method. If the optimizer picks an index for which this rowid filter can be applied, good. If not, not our problem. - When considering whether to use the rowid filter together with an index, make a cost-based choice between specified filters. There are some ideas about specifying the buffer size available for the rowid filter but they are outside of the scope of this MDEV. |
Description |
Add a new-style hint to control Rowid Filters.
{code:sql} /* +ROWID_FILTER( [table_name [index_name [ ...] ]]) */ /* +NO_ROWID_FILTER([table_name [index_name [ ... ] ]] ) */ {code} h2. Hint applicability Like {{NO_RANGE_OPTIMIZATION}} or {{MRR}}, the hint can apply to * Query block - {{NO_ROWID_FILTER()}} * Table - {{NO_ROWID_FILTER(table_name)}} * Specific index(es) - {{NO_ROWID_FILTER(table_name index1 index2 ...}} h2. Semantics h3. Semantics of NO_ROWID_FILTER Do not consider Rowid Filter for the scope of the hint (all tables in the query block, specific table, specific index(es)). h2. Semantics of ROWID_FILTER In short: Force use of ROWID_FILTER for the {{table.index}} it targets (?) h3. Possible semantics #1 At query block or table level it makes sense to have the meaning just "enable use of ROWID_FILTER". Assuming it is disabled globally. h3. Possible semantics #2 At index level, it would be nice to force use of indexes regardless of the costs. That is, {code:sql} SELECT /*+ ROWID_FILTER(t1 idx1) */ {code} would force the use of Rowid Filter made from t1.idx1 if the picked plan allows it, regardless of the costs. h3. A problem? Suppose we have implemented the logic: {quote} {{ROWID_FILTER(t1 idx1)}} makes the optimizer to use RowidFilter(idx1) if the access method to t1 allows it. {code} Then we run some query Q without any hints. Suppose the optimizer's choice is to use index idx2 for accessing table t1. Then we add the {{ROWID_FILTER(t1 idx1)}} to the Q and run it. When the optimizer looks for access method to t1, it picks idx2 and adds rowid filter(t1) . This makes the const higher than just using idx2. Use of {{idx2+RowidFilter(idx1)}} may become more expensive than e.g. full table scan. Or the join order may change. That is, the effect of the {{ROWID FILTER(t1 idx1)}} hint may be that some totally different plan will be used. h2. ... TODO: - When creating potential Rowid filters, only consider the specified indexes. - the ROWID_FILTER hint doesn't affect the choice of access method. If the optimizer picks an index for which this rowid filter can be applied, good. If not, not our problem. - When considering whether to use the rowid filter together with an index, make a cost-based choice between specified filters. There are some ideas about specifying the buffer size available for the rowid filter but they are outside of the scope of this MDEV. |
Add a new-style hint to control Rowid Filters.
{code:sql} /* +ROWID_FILTER( [table_name [index_name [ ...] ]]) */ /* +NO_ROWID_FILTER([table_name [index_name [ ... ] ]] ) */ {code} h2. Hint applicability Like {{NO_RANGE_OPTIMIZATION}} or {{MRR}}, the hint can apply to * Query block - {{NO_ROWID_FILTER()}} * Table - {{NO_ROWID_FILTER(table_name)}} * Specific index(es) - {{NO_ROWID_FILTER(table_name index1 index2 ...}} h2. Semantics h3. Semantics of NO_ROWID_FILTER Do not consider Rowid Filter for the scope of the hint (all tables in the query block, specific table, specific index(es)). h2. Semantics of ROWID_FILTER In short: Force use of ROWID_FILTER for the {{table.index}} it targets (?) h3. Possible semantics #1 At query block or table level it makes sense to have the meaning just "enable use of ROWID_FILTER". Assuming it is disabled globally. h3. Possible semantics #2 At index level, it would be nice to force use of indexes regardless of the costs. That is, {code:sql} SELECT /*+ ROWID_FILTER(t1 idx1) */ {code} would force the use of Rowid Filter made from t1.idx1 if the picked plan allows it, regardless of the costs. h3. A problem? Suppose we have implemented the logic: {quote} {{ROWID_FILTER(t1 idx1)}} makes the optimizer to use RowidFilter(idx1) if the access method to t1 allows it. {quote} Then we run some query Q without any hints. Suppose the optimizer's choice is to use index idx2 for accessing table t1. Then we add the {{ROWID_FILTER(t1 idx1)}} to the Q and run it. When the optimizer looks for access method to t1, it picks idx2 and adds rowid filter(t1) . This makes the const higher than just using idx2. Use of {{idx2+RowidFilter(idx1)}} may become more expensive than e.g. full table scan. Or the join order may change. That is, the effect of the {{ROWID FILTER(t1 idx1)}} hint may be that some totally different plan will be used. h2. ... TODO: - When creating potential Rowid filters, only consider the specified indexes. - the ROWID_FILTER hint doesn't affect the choice of access method. If the optimizer picks an index for which this rowid filter can be applied, good. If not, not our problem. - When considering whether to use the rowid filter together with an index, make a cost-based choice between specified filters. There are some ideas about specifying the buffer size available for the rowid filter but they are outside of the scope of this MDEV. |
Description |
Add a new-style hint to control Rowid Filters.
{code:sql} /* +ROWID_FILTER( [table_name [index_name [ ...] ]]) */ /* +NO_ROWID_FILTER([table_name [index_name [ ... ] ]] ) */ {code} h2. Hint applicability Like {{NO_RANGE_OPTIMIZATION}} or {{MRR}}, the hint can apply to * Query block - {{NO_ROWID_FILTER()}} * Table - {{NO_ROWID_FILTER(table_name)}} * Specific index(es) - {{NO_ROWID_FILTER(table_name index1 index2 ...}} h2. Semantics h3. Semantics of NO_ROWID_FILTER Do not consider Rowid Filter for the scope of the hint (all tables in the query block, specific table, specific index(es)). h2. Semantics of ROWID_FILTER In short: Force use of ROWID_FILTER for the {{table.index}} it targets (?) h3. Possible semantics #1 At query block or table level it makes sense to have the meaning just "enable use of ROWID_FILTER". Assuming it is disabled globally. h3. Possible semantics #2 At index level, it would be nice to force use of indexes regardless of the costs. That is, {code:sql} SELECT /*+ ROWID_FILTER(t1 idx1) */ {code} would force the use of Rowid Filter made from t1.idx1 if the picked plan allows it, regardless of the costs. h3. A problem? Suppose we have implemented the logic: {quote} {{ROWID_FILTER(t1 idx1)}} makes the optimizer to use RowidFilter(idx1) if the access method to t1 allows it. {quote} Then we run some query Q without any hints. Suppose the optimizer's choice is to use index idx2 for accessing table t1. Then we add the {{ROWID_FILTER(t1 idx1)}} to the Q and run it. When the optimizer looks for access method to t1, it picks idx2 and adds rowid filter(t1) . This makes the const higher than just using idx2. Use of {{idx2+RowidFilter(idx1)}} may become more expensive than e.g. full table scan. Or the join order may change. That is, the effect of the {{ROWID FILTER(t1 idx1)}} hint may be that some totally different plan will be used. h2. ... TODO: - When creating potential Rowid filters, only consider the specified indexes. - the ROWID_FILTER hint doesn't affect the choice of access method. If the optimizer picks an index for which this rowid filter can be applied, good. If not, not our problem. - When considering whether to use the rowid filter together with an index, make a cost-based choice between specified filters. There are some ideas about specifying the buffer size available for the rowid filter but they are outside of the scope of this MDEV. |
Add a new-style hint to control Rowid Filters.
{code:sql} /* +ROWID_FILTER( [table_name [index_name [ ...] ]]) */ /* +NO_ROWID_FILTER([table_name [index_name [ ... ] ]] ) */ {code} h2. Hint applicability Like {{NO_RANGE_OPTIMIZATION}} or {{MRR}}, the hint can apply to * Query block - {{NO_ROWID_FILTER()}} * Table - {{NO_ROWID_FILTER(table_name)}} * Specific index(es) - {{NO_ROWID_FILTER(table_name index1 index2 ...}} h2. Semantics h3. Semantics of NO_ROWID_FILTER Do not consider Rowid Filter for the scope of the hint (all tables in the query block, specific table, specific index(es)). h2. Semantics of ROWID_FILTER This should do something like "force use of ROWID_FILTER for the {{table.index}} it targets" but there are some issues: h3. Possible semantics #1 At query block or table level it makes sense to have the meaning just "enable use of ROWID_FILTER". Assuming it is disabled globally. h3. Possible semantics #2 At index level, it would be nice to force use of indexes regardless of the costs. That is, {code:sql} SELECT /*+ ROWID_FILTER(t1 idx1) */ {code} would force the use of Rowid Filter made from t1.idx1 if the picked plan allows it, regardless of the costs. h3. A problem? Suppose we have implemented the logic: {quote} {{ROWID_FILTER(t1 idx1)}} makes the optimizer to use RowidFilter(idx1) if the access method to t1 allows it. {quote} Then we run some query Q without any hints. Suppose the optimizer's choice is to use index idx2 for accessing table t1. Then we add the {{ROWID_FILTER(t1 idx1)}} to the Q and run it. When the optimizer looks for access method to t1, it picks idx2 and adds rowid filter(t1) . This makes the const higher than just using idx2. Use of {{idx2+RowidFilter(idx1)}} may become more expensive than e.g. full table scan. Or the join order may change. That is, the effect of the {{ROWID FILTER(t1 idx1)}} hint may be that some totally different plan will be used. h2. ... TODO: - When creating potential Rowid filters, only consider the specified indexes. - the ROWID_FILTER hint doesn't affect the choice of access method. If the optimizer picks an index for which this rowid filter can be applied, good. If not, not our problem. - When considering whether to use the rowid filter together with an index, make a cost-based choice between specified filters. There are some ideas about specifying the buffer size available for the rowid filter but they are outside of the scope of this MDEV. |
Link | This issue split from MDEV-33281 [ MDEV-33281 ] |
Link | This issue relates to MDEV-33281 [ MDEV-33281 ] |
Fix Version/s | 12.1 [ 29992 ] | |
Fix Version/s | 12.0 [ 29945 ] | |
Sprint | Server 12.1 dev sprint [ 793 ] | |
Assignee | Sergei Petrunia [ psergey ] | |
Issue Type | Task [ 3 ] | New Feature [ 2 ] |
Assignee | Sergei Petrunia [ psergey ] | Oleg Smirnov [ JIRAUSER50405 ] |
Labels | optimizer-12.1-sprint |