Questions tagged «btree»

显示按顺序输入键（1、2、3、4、5）到初始为空的B + –m = 3的树的记录结果。如果发生溢出，请分割节点，不要重新分配邻居的钥匙。是否可以以不同的顺序使用键输入记录以使树的高度减小？ 从Relational DBMS Internals，第5章：动态树结构组织，第50页 我对此并不擅长，但我尝试在左侧做≤，在右侧做>： 直到插入1,2： 然后，就我们必须拆分节点而不要将密钥重新分配给邻居（我理解为子节点）而言，我仅在单元格右侧插入了2： 当插入5时，我继续做同样的事情： 但这很奇怪，我从未见过像这样的空节点...而且我不知道它是否尊重一些非常基本的B树属性： 每个节点最多具有（m-1）个键，并且至少具有（⌈（m / 2）⌉-1）个键，除非键可以为空，并且我会将键理解为“指针”。 第一次尝试：订单错误显示一棵模糊的树 一开始，我误解了“顺序”是什么（每个节点的最大子节点数）。所以我认为一个节点可以有3个空格（因此有4个孩子。我正在创建4阶树）： 直到插入1,2,3为止： 插入4，至于我们必须拆分节点并且不将密钥重新分配给邻居（这似乎是矛盾的），我会让1,2,3和4,5在3之后的右叶上：

11 btree 

对于支持哈希索引的每个Postgres版本，都有警告或注意，至少在8.3版之前，哈希索引比btree索引“相似或更慢”或“不更好” 。从文档： 版本7.2： 注意：由于哈希索引的用途有限，因此通常应优先选择B树索引而不是哈希索引。我们没有足够的证据表明即使进行=比较，哈希索引实际上也比B树更快。而且，散列索引需要更粗的锁。参见第9.7节。 版本7.3（以及最高8.2）： 注意：测试表明PostgreSQL的哈希索引与 B树索引相似或比B树索引慢，并且哈希索引的索引大小和构建时间要差得多。在高并发下，哈希索引的性能也很差。由于这些原因，不鼓励使用哈希索引。 版本8.3： 注意：测试表明PostgreSQL的哈希索引的性能并不比B树索引好，并且哈希索引的索引大小和构建时间要差得多。此外，哈希索引操作目前还没有进行WAL记录，因此在数据库崩溃后可能需要使用REINDEX重建哈希索引。由于这些原因，目前不鼓励使用哈希索引。 他们声称在此版本8.0线程中，从未发现哈希索引实际上比btree更快的情况。 即使是在9.2版中，根据该博客文章（2016年3月14日）： AndréBarbosa撰写的Postgres哈希索引，除编写实际索引外，其他任何方面的性能提升也几乎没有。 我的问题是那怎么可能？ 根据定义，哈希索引是一个O(1)操作，其中btree是一个O(log n)操作。那么，O(1)查找比查找正确的分支然后查找正确的记录要慢（或什至类似于）的可能性如何呢？ 我想知道索引理论到底有什么可能！

8 postgresql  index  btree  hashing