Note:
This topic has been translated from a Chinese forum by GPT and might contain errors.
Original topic: hint join时表名的指定
Documentation is unclear or incomplete, please submit according to the template below:
-
Issue Category: Content too brief, unclear description with ambiguities, incomplete steps
-
Page where the issue occurs: Documentation link: Optimizer Hints | PingCAP 文档中心
-
Issue Description:
When we use /+ HASH_JOIN(m1,m2) /, if m1 and m2 are not in the same database, the following error will occur: There are no matching table names for (m1, m2) in optimizer hint /+ HASH_JOIN(m1, m2). However, our table names are correct, and using the following format can make hash_join work normally:
/+ HASH_JOIN(db1.m1,db2.m2) */
Therefore, we hope this point can be included in the documentation.
The request has been forwarded, thank you for your feedback, Chaochao. I will update you once there is progress.
The hint mentioned here, but it should also be applicable to other hints involving multiple tables. The documentation can be optimized.
Indeed, I didn’t notice this here. I feel that placing this note about the library name at the outermost layer would be better. Here, it feels like a feature of read_from_storage. There was no explanation earlier, giving me the impression that just specifying the table name would be sufficient.
Actually, I feel that while being compatible with MySQL hints, a set of TiDB hint syntax should be designed. I think MySQL’s hints are too limited and lack flexibility. For example, when I want the optimizer to specify an index scan, it doesn’t necessarily have to specify which index to use; the optimizer can provide the best index scan. Similarly, during a join, I could directly specify in the join hint which operator is the outer table, using keywords like first=true.
I support this idea. While being compatible with MySQL, developing a more efficient and user-friendly set of hints or other methods to control execution plans is also important. The official team should be working on this. Previously, there was a post suggesting that features like pushdown blacklists and distsql concurrency should be implemented in the form of hints. The official response was that there are plans for this. Currently, there are already hints like LEADING and NO_DECORRELATE.
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.
|
username: db_user
|
username: 
|
username: 
|
username: 
|
username: