Postgres 中的按位运算

发布于 2025-01-04 11:29:40 字数 1101 浏览 4 评论 0原文

我有以下表格:

types | id | name
------+----+----------
         1 | A
         2 | B
         4 | C
         8 | D
         16| E
         32| F

vendors | id | name     | type
--------+----+----------+-----
           1 | Alex     | 2     //type B only
           2 | Bob      | 5     //A,C
           3 | Cheryl   | 32    //F
           4 | David    | 43    //F,D,A,B
           5 | Ed       | 15    //A,B,C,D
           6 | Felix    | 8     //D
           7 | Gopal    | 4     //C
           8 | Herry    | 9     //A,D
           9 | Iris     | 7     //A,B,C
           10| Jack     | 23    //A,B,C,E

现在想查询:

select id, name from vendors where type & 16 >0 //should return Jack as he is type E
select id, name from vendors where type & 7 >0 //should return Ed, Iris, Jack
select id, name from vendors where type & 8 >0 //should return David, Ed, Felix, Herry 

postgres 中表 typesvendors 的最佳索引是什么?我可能有数百万行供应商。此外,与使用第三个表的多对多关系相比,使用这种按位方法有什么权衡?哪个更好?

I have the following tables:

types | id | name
------+----+----------
         1 | A
         2 | B
         4 | C
         8 | D
         16| E
         32| F

and

vendors | id | name     | type
--------+----+----------+-----
           1 | Alex     | 2     //type B only
           2 | Bob      | 5     //A,C
           3 | Cheryl   | 32    //F
           4 | David    | 43    //F,D,A,B
           5 | Ed       | 15    //A,B,C,D
           6 | Felix    | 8     //D
           7 | Gopal    | 4     //C
           8 | Herry    | 9     //A,D
           9 | Iris     | 7     //A,B,C
           10| Jack     | 23    //A,B,C,E

I would like to query now:

select id, name from vendors where type & 16 >0 //should return Jack as he is type E
select id, name from vendors where type & 7 >0 //should return Ed, Iris, Jack
select id, name from vendors where type & 8 >0 //should return David, Ed, Felix, Herry 

What is the best possible index for tables types and vendors in postgres? I may have millions of rows in vendors. Moreover, what are the tradeoffs of using this bitwise method compared with Many To Many relation using a 3rd table? Which is better?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

娜些时光,永不杰束 2025-01-11 11:29:40

使用可以使用部分索引来解决“&”这一事实不是可索引运算符(据我所知):

CREATE INDEX vendors_typeA ON vendors(id) WHERE (type & 2) > 0;
CREATE INDEX vendors_typeB ON vendors(id) WHERE (type & 4) > 0;

当然,每次添加新类型时都需要添加新索引。这是将数据扩展为关联表的原因之一,然后可以正确地对其进行索引。您始终可以编写触发器来额外维护位掩码表,但使用多对多表来实际正常维护数据,因为它会更清晰。

如果您对扩展和性能的整个评估是“我可能有数百万行”,那么您还没有做足够的事情来开始进行这种优化。首先创建一个结构合理的清晰模型,然后根据有关其性能的真实统计数据对其进行优化。

Use can use partial indices to work around the fact that "&" isn't an indexable operator (afaik):

CREATE INDEX vendors_typeA ON vendors(id) WHERE (type & 2) > 0;
CREATE INDEX vendors_typeB ON vendors(id) WHERE (type & 4) > 0;

Of course, you'll need to add a new index every time you add a new type. Which is one of the reasons for expanding the data into an association table which can then be indexed properly. You can always write triggers to maintain a bitmask table additionally, but use the many-to-many table to actually maintain the data normally, as it will be much clearer.

If your entire evaluation of scaling and performance is to say "I may have millions of rows", you haven't done enough to start going for this sort of optimisation. Create a properly-structured clear model first, optimise it later on the basis of real statistics about how it performs.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文