[2023 Others]: Summary

[luooofan]

这是第二次参赛了，截个英雄榜纪念🎉🎉🎉

PS：榜一是师兄，zhaoyiping0622 (zhaoyiping) 平队 NB！

---

队伍

先说一下今年的队伍配置，我和 @Zhang-X0 成林是去年参加过，@Jingluo-nan 向南是今年第一次打，我们三完全线下面对面交流

今年我们打比赛的时间有限，但是两位队友非常给力，把闲余时间都大量地投入到了比赛里面去，其他事情都放了放，非常辛苦

而且分出去的赛题队友都能很好的完成，还能有一些个惊喜，非常 nice

---

赛前准备

今年 miniob 的比赛代码和去年相比变化还是蛮大的，可以非常清晰的感知到 parser resolver rewriter plan_generator 这块儿的显著变化，阶段划分清晰，内部功能明确，paser 语法树 -> 逻辑算子树 -> 物理算子树的结构也非常合理。所以我们并没有打算在去年代码的基础上做，而是从头开始在新的 miniob 上实现功能，当然很多功能的实现思路是类似的

赛前先是添加了一些基本组件，luooofan/miniob-2023 at 2023-add_foundation：

• 拓充 build.sh 的功能，把 gen parser、test all cases、test single case、diff single case 等常用操作集成进去
• 拓充 tasks.json，把上面拓充的功能集成到 vscode tasks 中去
• 拓充 lauch.json，用 gdb launch/attach
• 添加 issue 和 pr 模板，issue 分三类，topic，case failed，others
• 添加 clang-format，但是一直没找到一个合适的时间节点来启用这个，以后还是应该尽早启用
• 添加 clang-tidy，限制检查 sql 目录之后 ok，但加个 storage 目录就报错太多了，也就没用这个（后来平队发现可以只对 git diff xxx 的结果进行检查，而且我看最新的 cmu 15445 也支持 diff clang-tidy，就集成了一下，可惜还是没用起来，以后还是应该尽早启用）

分支管理等沿用去年的原则，参见 #43

然后今年仗着有去年参赛的经验，紧迫性不高，没怎么提前做题，比赛前就向南做了四五道题练手，然后我比赛开始那两天在做 null，成林在做 multi-index，开赛前两天我记得是 rebase 完之后拿到了 50 分，但是榜单上两三百分的队伍已经有一大堆了……

---

赛题

总览

赛题总体上大致可以分为两块，一块是 sql 层的部分，对应 sql 目录，一块是存储层的部分，对应 storage 目录

抛开最上面几个练手题，剩下的赛题：

sql 层：

• 表达式
  • 子查询表达式
• 算子

storage 层：

• 索引
• text

还有一些赛题是两块都有涉及，比如 insert update，create-tabel-select，create-view 等

任务分配

• 成林这边，在 update、索引做完以后，接着做几个比较独立的赛题
• 向南这边，先做了一些简单题熟悉之后，负责表达式和算子这块
• 我这边比较杂，null，join-tables，alias，子查询表达式，过程中调整调整 sql 层的代码，review 部分成林做的赛题

做题顺序

我们的做题顺序基本符合上图中 从上到下 的一个顺序，从题目依赖的角度来看主要有几个问题：

• 子查询做的太迟了，把 alias、update-select、null 测例都卡住了
• view 做的太迟了，导致 sql 层这边要改很多。参考 [2023 Topic]: View #45 ，可以先把BaseTable提取出来，view后面再实现
• 虽然已经提前做 expression 了，但是应该更早做，而且要做的彻底，把 select clause，insert/update value 都给改了，condition 这边直接把 and 和 or 支持了

另外，对题目进行适当重排和组合还是有必要的：

• 先做 null，然后做其他赛题的时候把 null 考虑进去
• 先做 expression，再做 aggr-function，function，alias，子查询等
• 做 aggr-function 的时候把 group-by 算子部分的代码写好
• 可以不提前考虑 big-xxx，等做完相应的功能以后再本地构造测例测试，跑火焰图，然后针对性优化

赛题思路

今年仓库的 issue 和 pr 弄的不错，具体的赛题可以找对应的来看，这里就不细说了

罗列一下问题和建议：

• join tables 偷懒把算子下推做在了语义解析这边，增加了这边的复杂度，后面直接把下推给删了
• alias 做的太简单了，没有考虑 from t1 t11, t1 t12 这种情况，而且这个 case 不在 alias 的测例里，而在 create-view 的测例里，最后打了个补丁上去 [2023 Case Failed]: alias #44
• select stmt create 在做的过程中没有从总体上去考虑它，等都实现完以后我们才重新捋了一遍 [2023 Others]: rethink select stmt resolver #40
• 实现物理算子时应该遵循一些原则 [2023 Others]: rethink physical operator impl principles #39
• 对 expression 树有很多遍历操作，比如语义解析，深拷贝等，可以预实现一个后序遍历 [2023 Topic]: aggr_function #24 (comment)
• 没做 update-mvcc 就过了，后面也没补做
• 查询没走 index
• 代码里还留了一些 bug，client 没法通过 port 连过去，rewrite 在最后复杂子查询引入了一个 bug，etc，懒得修了

---

其他

今年的赛题，除了 unique 卡了卡，其他的都做的很顺，没有遇到奇怪的 bug，也没用二分评测这种方法

今年比起去年虽然有些题目没了，但是嵌入在了某个赛题里边，比如 batch-insert，update-columns，typecast 等

今年的一些优势，比如 issue 和 pr 的维护，review 代码进行代码结构的调整和优化，在只剩最后几个赛题的时候没有很好的保持下去

今年我们一开始就想着在新的 miniob 上重做功能，也没有试过直接提交去年的代码，后来才知道直接提交我们去年比赛仓库的代码就可以拿到 300 分左右。这里就给大家提个醒，大家打比赛的话还是要注意一下

create-view 没有合到主分支中去

平队的 Summary Summary · Issue #1 · zhaoyiping0622/miniob

---

最后

希望对大家有帮助⭐，over