本文主要是介绍【0323】Postgres内核之 hash table sequentially search（seq_scan_tables、num_seq_scans），希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
0. seq scan tracking
我们在这里跟踪活跃的 hash_seq_search() 扫描。 需要这种机制是因为如果扫描正在进行时发生桶分裂（bucket split），它可能会访问两次相同的条目，甚至完全错过某些条目（如果它正在访问同一个分裂的桶中的条目）。因此，如果正在向表中插入数据，我们希望抑制桶分裂。 在当前的使用中，这种情况非常罕见，因此只需将分裂推迟到下一次插入即可。
鉴于当前对该函数的使用情况，同时打开的扫描可能只有几个，因此一个有限大小的开放扫描栈似乎就足够了，我们也不担心线性搜索太慢。 请注意，我们允许同时打开多个相同的哈希表的扫描。
如果在同一个后端同时进行扫描和插入操作，这种机制可以在共享哈希表中支持并发扫描和插入操作。如果不是在同一个后端进行这两种操作，则会失败，但由于锁定原因似乎排除了这种情况，所以我们不用担心。
如果临时哈希表被删除而没有通知我们，这种安排将具有相当的健壮性。最糟糕的情况是我们可能会在稍后创建的另一个表中阻止分裂操作，而该表恰好占用了相同的地址。我们会在事务结束时给出一个警告，以提示可能的内存泄露，因此任何导致缺乏通知的错误都应该很容易被发现。
1. max seq s
这篇关于【0323】Postgres内核之 hash table sequentially search（seq_scan_tables、num_seq_scans）的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
