【问题标题】:How brin index performs on non temporal data when compared with btree index in postgresql?与 postgresql 中的 btree 索引相比,brin 索引在非时态数据上的表现如何?
【发布时间】:2020-07-06 18:50:34
【问题描述】:

我正在阅读以下关于在时态数据上与 btree 相比带来索引性能的博文。

https://info.crunchydata.com/blog/postgresql-brin-indexes-big-data-performance-with-minimal-storage

问题:

  1. 我想知道 brin 索引的使用仅限于像 timestampz 这样的时间数据,或者它是否可以用于非时间数据,比如在列上定义 brin 索引,比如说 user_id。

  2. 何时使用 b-tree 索引与 brin 索引?

任何指针将不胜感激。谢谢。

【问题讨论】:

    标签: postgresql indices


    【解决方案1】:

    您可以为任何支持 B-tree 索引的数据类型使用 BRIN 索引,即具有总排序的数据类型(可以比较任意两个值)。

    但您可以几乎从不使用 BRIN 索引。仅当表中行的物理顺序与您要索引的列值的逻辑顺序相同或完全相反时,它们才有效。

    所以,使用整数,下表就可以了:

    +--------------+----------------+------
    |1 4 6 7 12 14 | 17 16 29 31 44 | ...
    +--------------+----------------+------
       8kB block       8kB block
    

    观察到排序并不完美:值为 17 的行在值为 16 的行之前。但它足够接近,不会干扰块范围内的最小值和最大值(默认为 128 个块)。

    但是,如果每个区块范围只有一个异常值,则 BRIN 索引将变得毫无用处。

    因此,您只能在仅插入的表上使用这些索引,在这些表中,插入的行的索引列的值不断增加(或减少)(典型的时间序列),或者如果您可以人为地以适当的方式重写表订单(数据仓库)。

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 1970-01-01
      • 2017-06-25
      • 2016-10-30
      • 1970-01-01
      • 2022-01-14
      • 1970-01-01
      • 1970-01-01
      • 2019-10-02
      相关资源
      最近更新 更多