首页   注册   登录
 reus 最近的时间轴更新
ONLINE

reus

V2EX 第 4901 号会员,加入于 2011-01-07 21:26:37 +08:00
今日活跃度排名 1191
开源一个前端框架,欢迎试用、点评
前端开发  •  reus  •  2017-02-22 11:57:56 AM  •  最后回复来自 reus
4
加密代理 gotunnel
分享创造  •  reus  •  2015-07-02 01:16:09 AM  •  最后回复来自 senggai
51
reus 最近回复了
1 分钟前
回复了 hellowes 创建的主题 职场话题 好奇 996 工作制真的会猝死吗?
@likai 8 点到 11 点就一班?你别造谣啊
“因为可以不经 80 端口访问 443,这样就实现了免备案。”,访问 443 本来就不经 80,备案针对的是域名,就算你用 12345 端口,也一样需要备案,只不过没人理你的 12345 而已……
16 小时 35 分钟前
回复了 FakeLeung 创建的主题 问与答 为什么放假机制不能学下香港的?
刺激旅游
18 小时 27 分钟前
回复了 woxibohua 创建的主题 酷工作 [江苏无锡] 电机制造企业招全栈 1 人,税前 25 万起
v2ex 没有学历门槛,小心被水货坑了!建议还是找正规招聘网站
21 小时 36 分钟前
回复了 kyf0722 创建的主题 PostgreSQL pg 的前辈们进来帮看看索引的问题
如果存储是 SSD,用 SET random_page_cost = 1; 看有没有改善。bitmap index scan 的目的是减少不必要的 page read,因为贵。但如果随机读 page 的成本低,planner 会倾向于直接读而不是用 bitmap index scan。

还有个可能的原因是物理存储位置太分散,也会用 bitmap index scan,试下 vacuum full notice
1 天前
回复了 kyf0722 创建的主题 PostgreSQL pg 的前辈们进来帮看看索引的问题
work_mem 太小可能是原因,但 work_mem 小并没有导致排序慢,而是触发了 recheck cond,所以才慢

Bitmap Index Scan 这一步,如果 work_mem 太小,它不会返回 row id 而是 page id,这样就需要 Bitmap Heap Scan 里 recheck 这一步,因为一个 page 可能有不符合条件的 row。

排序并不慢,Bitmap Heap Scan 实际跑了 205.214 毫秒,加上排序是 214.520 ,占比不高。
你想签那么久它还未必肯呢,几十年没有通胀吗
活该被骗。真的。
看你语文这种水平,觉得被骗也合理
关于   ·   FAQ   ·   API   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   3666 人在线   最高记录 4385   ·  
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.3 · 11ms · UTC 01:23 · PVG 09:23 · LAX 18:23 · JFK 21:23
♥ Do have faith in what you're doing.
沪ICP备16043287号-1