urgent_client 单独启一个 worker 咯
fuzzystrmatch 是 default,但和这个还是有点差异
fixed.
release as a pg extension: https://github.com/hooopo/pg-fuzzywuzzy
后面两个没利用到 idx 啊
在上例中,我是需要同时对这两列创建一个新的 tsvector 的列并加索引吗?
你的过滤条件是什么,就在上面加表达式索引就好了,其实没必要加一个 tsv 列,还需要去同步。
继续使用 pg_search 的话,其实你完全可以冗余一个列叫 title_and_desc,然后和单字段一样的做法。
你要把 sql log 和 explain 发上来,web 请求的截图没用啊
你的需求其实直接搜 title || desc
就可以了
acts as xx
不会很大,可以 sharding 的
你可以拼出 edit 链接的
都重要,baas 主要就三点,schemaless 存储,云服务需要,但私有部署的不需要,比如 husura,serverless 其实是用来实现复杂业务需求的,另一个就是 ACL or RLS.SDK 或文档任何云服务都需要的
遇到神奇 bug 了
from twitter:
Me 5 years ago: Use services oriented architecture for all your code!
Me 3 years ago: Use CQRS/ES for all your code!
Me now: Just use PostgreSQL
https://twitter.com/hubertlepicki/status/1073229975254392832
pg 是用了就回不去的存在
为什么可以吃西红柿却不可以吃水果
😂
这个就要写长文批判了
搜索替代不了标签吧,多肽确实反模式,但 Rails 里方便…
比不上 es 是肯定的 但也够用
负载是什么
English needed?
搜 scatter_swap obfuscate_id
最近用 Pg 实现了一个 Instagram Style ID,可供参考,32 位的 integer 也差不多,只不过碰撞几率就大了:
bigint 范围 -9223372036854775808 到 9223372036854775807,9223372036854775807 也就是:
select 9223372036854775807::bit(64);
bit
------------------------------------------------------------------
0111111111111111111111111111111111111111111111111111111111111111
把 64 位的 bigint 分三段,第一段是 41 位 bit 的时间(可存 69 年),第二段是 13 位的 shard_id(可存 8191 个),第三段是 10 个 bit 的自增序列(可存 1024 个)
time | shard | seq
-------------------------------------------+---------------+------------
11111111111111111111111111111111111111111 | 1111111111111 | 1111111111
一年的毫秒数:31556952000,所以,41 位的 bit 可以存 69 年。
select b'11111111111111111111111111111111111111111'::bigint / 31556952000;
?column?
----------
69
13 位 bit 的 shard_id:
select b'1111111111111'::bigint;
int8
------
8191
10 位的自增 seq:
select b'1111111111'::bigint;
int8
------
1023
所以,每毫秒每个 shard 可以产生 1023 个唯一 ID。
代码:
def change
execute("create schema id_pool")
execute("create sequence id_pool.table_id_seq")
execute(<<~SQL)
CREATE OR REPLACE FUNCTION id_pool.next_id(OUT result bigint) AS $$
DECLARE
our_epoch bigint := 1546300800000; /* 2019-01-01 单位ms */
seq_id bigint;
now_millis bigint;
shard_id int := 1;
BEGIN
SELECT nextval('id_pool.table_id_seq') % 1024 INTO seq_id;
SELECT FLOOR(EXTRACT(EPOCH FROM clock_timestamp()) * 1000) INTO now_millis;
result := (now_millis - our_epoch) << 23;
result := result | (shard_id << 10);
result := result | (seq_id);
END;
$$ LANGUAGE PLPGSQL;
SQL
end
instagram article: http://instagram-engineering.tumblr.com/post/10853187575/sharding-ids-at-instagram
用 pg 还真能实现,es 嘛就算了,得引 groovy script
PM 是实习生吗
感觉可以不用 view 了,jsonb 也不需要了,直接动态创建一个 table,反正 pg 的增加和删除 column 是不锁表的,限制 alter column type 之类就行...
公司名称是什么