时间复杂度&&；PostgreSQL中的运算符

给定一个程序，例如

SELECT (regexp_split_to_array(...)) && SELECT (regexp_split_to_array(...))

当我试图检查两个集合是否产生至少一个相同的元素时，我想知道这个代价有多大，担心这个问题是否有意义

---

更完整的视图：

CREATE POLICY mytable_policy
ON mytable
USING (
        CASE WHEN ... THEN TRUE
             ELSE (SELECT (regexp_split_to_array((SELECT current_setting('my.stuff')), ':')))
                                                &&
                  (SELECT (regexp_split_to_array(mystuff, ':')))
        END
      )
WITH CHECK (true);

感谢您的关注。

快速查看for array1和&array2，复杂性是O（L1*L2），其中L1和L2是array1和array2的长度。它遍历array1，然后对每个元素遍历array2，直到找到匹配项

如果阵列较短，这很可能不是问题，如果阵列较长，则速度可能较慢。由于循环在找到的第一个匹配项处停止，因此将最频繁的元素放在数组的第一位是有意义的

请注意，可以在表中存储数组。无需将它们存储为以“：”分隔的字符串，并每次重新生成它们。这是一个包含1000行的表，其中的文本列“t”的值为'a:B:C:D:E:F:G:H:I:J:K:L:M:N:O:P:Q:R:t:U:V:W:X:Y:Z'，文本[]列包含数组{a，B，C，D，E，F，G，H，I，J，L，M，N，O，P，Q，R，S，t，U，V，W，X，Y}

test=> EXPLAIN ANALYZE SELECT string_to_array(t,':') FROM foo;
 Execution time: 5.334 ms

test=> EXPLAIN ANALYZE SELECT regexp_split_to_array(t,':') FROM foo;
 Execution time: 40.640 ms

test=> EXPLAIN ANALYZE SELECT a FROM foo;
 Execution time: 0.488 ms

如您所见，将其存储为文本是一个非常糟糕的主意，使用regexp函数更糟糕。只需使用数组列，速度会快得多。。。现在，&&运算符需要多长时间

test=> EXPLAIN ANALYZE SELECT regexp_split_to_array(t,':') && '{M,N,Z}'::TEXT[] FROM foo;
 Execution time: 42.055 ms

test=> EXPLAIN ANALYZE SELECT a && '{M,N,Z}'::TEXT[] FROM foo;
 Execution time: 1.944 ms

在1.9ms内处理1000行，因此运行&&操作符的时间不到2µs。所以，是的，除非阵列很大，否则没问题

如果您想做得过火，可以使用jsonb类型。这个数组包含一个关联数组，如{'A'：1，'B'：2…等…}

test=> EXPLAIN ANALYZE SELECT j ?| '{M,N,Z}'::TEXT[] FROM foo;
 Execution time: 1.041 ms

稍微快一点，但我不确定这是否有更好的复杂性。这取决于jsonb代码如何以及是否散列键。如果对jsonb对象的键查找是O（1），那么整个操作将是O（L1），这比array2大时的O（L1*L2）要好

EDIT：表示它使用线性搜索，不散列键，因此jsonb不会有更好的复杂性

---

如果您想做得过火，还可以使用位图或位字符串，将存在的属性的位设置为1。这使得重叠操作O（1），但当然每个属性在位字符串中都被分配了一个固定的位位置，这很麻烦。

好吧，其他部分可以简化为

regexp_split_to_数组（crent_设置（'my.stuff'），'：'）和®exp_split_to_数组（mystuff'，：'）

选择在那里是零意义的。给定{a，b，c}和{d，e，f}我担心这样的事情会发生：a==d，a==e，a==f，b==d，b==e，b==f，c==d，c==e，c==f这就是o（n^2），这就是为什么我是asking@a_horse_with_no_name我应该删除这个问题吗？因为一些Postgres的开发人员在闲逛，所以他们实际上可能会透露一些实现细节。这是一个非常狭窄的用例，老实说，在RLS策略的上下文中，我并不真正关心它。与检查两个（据说很小）阵列相比，还有其他一些因素对性能的影响更大。如果

string\u to_array

的开销高于

&&

操作符，我不会感到惊讶。但我认为你的问题不值得投否决票，这是有道理的。感谢您的帮助@a_horse_与_no_name一个位字符串仍然是

O（n）

，而

n

是位数（可能的元素数）。我建议看一看保持整数排序的数组，求交的复杂性（

k

是使用的元素数，即比稀疏数组的位字符串好得多）好的捕获，还有hstore。