V2EX › kyf0722 的所有回复 › 第 5 页 / 共 6 页

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

1 2 3 4 5 6

❮

❯

2019-03-27 20:30:12 +08:00

回复了 kyf0722 创建的主题 › Apple › 升级 Mojave 10.14.4 之后经常无法盒盖使用显示器

@mTerminal 肯定插了啊

2019-03-27 09:51:49 +08:00

回复了 kyf0722 创建的主题 › Apple › 升级 Mojave 10.14.4 之后经常无法盒盖使用显示器

@kingdream123 看来是升出 bug 了

2019-03-24 00:25:52 +08:00

回复了 kyf0722 创建的主题 › PostgreSQL › pg 的前辈们进来帮看看索引的问题

@reus 抱歉, 错了, 请忽略上条回复. work_mem 加到 512M 之后, 的执行结果

"Limit (cost=51977.56..51977.58 rows=10 width=134) (actual time=112.037..112.044 rows=10 loops=1)"
" -> Sort (cost=51977.56..52021.04 rows=17394 width=134) (actual time=112.034..112.037 rows=10 loops=1)"
" Sort Key: public_time DESC"
" Sort Method: top-N heapsort Memory: 29kB"
" -> Bitmap Heap Scan on notice (cost=2017.69..51601.68 rows=17394 width=134) (actual time=30.136..103.225 rows=18635 loops=1)"
" Recheck Cond: (type = 31)"
" Filter: (area ~ '^110'::text)"
" Heap Blocks: exact=15625"
" -> Bitmap Index Scan on area_type_public_time_desc (cost=0.00..2013.34 rows=17386 width=0) (actual time=22.173..22.173 rows=18635 loops=1)"
" Index Cond: ((area ~>=~ '110'::bpchar) AND (area ~<~ '111'::bpchar) AND (type = 31))"
"Planning Time: 0.571 ms"
"Execution Time: 112.108 ms"

还是触发了 Recheck

2019-03-24 00:21:58 +08:00

回复了 kyf0722 创建的主题 › PostgreSQL › pg 的前辈们进来帮看看索引的问题

@reus 这位仁兄说的很有道理

我索性直接把 work_mem 加到了 512M, 但是执行结果更加匪夷所思
"Limit (cost=118704.89..118704.92 rows=10 width=134) (actual time=688.049..688.057 rows=10 loops=1)"
" -> Sort (cost=118704.89..118816.86 rows=44786 width=134) (actual time=688.047..688.049 rows=10 loops=1)"
" Sort Key: public_time DESC"
" Sort Method: top-N heapsort Memory: 27kB"
" -> Bitmap Heap Scan on notice (cost=1869.15..117737.08 rows=44786 width=134) (actual time=47.015..663.260 rows=44366 loops=1)"
" Filter: ((area ~ '^110'::text) AND (type <> 31))"
" Rows Removed by Filter: 18635"
" Heap Blocks: exact=39610"
" -> Bitmap Index Scan on area_type_public_time_desc (cost=0.00..1857.96 rows=62153 width=0) (actual time=28.356..28.356 rows=63001 loops=1)"
" Index Cond: ((area ~>=~ '110'::bpchar) AND (area ~<~ '111'::bpchar))"
"Planning Time: 0.578 ms"
"Execution Time: 688.124 ms"

无法理解了!!, 多次执行都差不多

2019-03-24 00:13:07 +08:00

回复了 kyf0722 创建的主题 › PostgreSQL › pg 的前辈们进来帮看看索引的问题

@zbinlin

pg 默认的 work_mem 是 4M maintenance_work_mem 是 64M
我修改当前 session 的 work_mem 到 128M, maintenance_work_mem 到 512M
然后 drop index, 再重新 create index

同样上面带 order by 的查询语句执行结果
```
"Limit (cost=51977.56..51977.58 rows=10 width=122) (actual time=126.678..126.685 rows=10 loops=1)"
" -> Sort (cost=51977.56..52021.04 rows=17394 width=122) (actual time=126.676..126.678 rows=10 loops=1)"
" Sort Key: public_time DESC"
" Sort Method: top-N heapsort Memory: 29kB"
" -> Bitmap Heap Scan on notice (cost=2017.69..51601.68 rows=17394 width=122) (actual time=35.036..117.511 rows=18635 loops=1)"
" Recheck Cond: (type = 31)"
" Filter: (area ~ '^110'::text)"
" Heap Blocks: exact=15625"
" -> Bitmap Index Scan on area_type_public_time_desc (cost=0.00..2013.34 rows=17386 width=0) (actual time=28.123..28.123 rows=18635 loops=1)"
" Index Cond: ((area ~>=~ '110'::bpchar) AND (area ~<~ '111'::bpchar) AND (type = 31))"
"Planning Time: 0.615 ms"
"Execution Time: 126.819 ms"
```

比刚刚确实快一些, 但是排序似乎还是和索引没有关系, 如果我把 order by 的 public_time 替换为 id, 可以在 2-5ms 内查出数据

@xiangyuecn Sort Method: top-N heapsort Memory: 29kB 中的 29kB 应该是排序使用了 29K 的内存, 我试过如果数据量巨大, 内存不够的时候会显示 disk size, 也就是用到了磁盘

2019-03-19 09:26:33 +08:00

回复了 xiaopanzi 创建的主题 › macOS › Apple 账号无法绑定美区 paypal

我 palpay 刚注册完那会也无法绑定, 隔了半年(期间有过一两笔消费), 想起来了试了一下就绑定成功了

2019-03-15 09:20:43 +08:00

回复了 JSheilaYB087 创建的主题 › 问与答 › 联通停止 eSIM 试验业务的服务？莫非是准备关了 VoLTE？

eSim 和 VoLTE 没有关系!

2019-03-13 11:13:15 +08:00

回复了 ljwaheng 创建的主题 › Apple › 今年 Apple 春季发布会有可能会更新 MacBook Pro 吗？

mac 更新会在 6-7 月份

2019-03-13 10:02:15 +08:00

回复了 gongbin 创建的主题 › Apple › 现在美区 Apple ID 可以在支付方式选择 None 的情况下使用 gift card 充值买应用吗？不绑定信用卡和 PayPal

可以的