背景

1、产品的问题点

• PG 不支持索引随机采样

2、问题点背后涉及的技术原理

• 随机采样扫描用于返回随机数据. PG内置了表的随机采样方法, 例如按数据块随机采样、按记录随机采样.
• 但是无法采用固定扫描方法进行随机采样, 例如有where条件的SQL, 符合条件的有10万条, 但是期望随机返回100条. 目前的方法是取得10万条后随机排序返回, 或者给定一个随机数返回.

• • select * from x where xxx order by random() limit x; 机会公平, 但是需要扫描所有符合条件的记录, 同时增加了排序成本
  • select * from x where xxx and random() < xx limit x; 跳过不满足条件的行, 但是这种方法的机会不公平, 很容易导致无法获取到索引扫描末尾符合条件的行.
  • 以上都会导致过度计算, 目前PG无法在索引扫描方法上根据符合条件的index block再随机扫描

3、这个问题将影响哪些行业以及业务场景

• 通常被用于推荐系统, 在满足条件的记录范围内进行随机推荐.

4、会导致什么问题?

• 导致过度计算

5、业务上应该如何避免这个坑

• 暂时没有特别好的方法, 除非改业务逻辑
• 《重新发现PostgreSQL之美 - 26 这个推荐算法价值1亿》

6、业务上避免这个坑牺牲了什么, 会引入什么新的问题

• 需要非常专业的知识

7、数据库未来产品迭代如何修复这个坑

• 希望内核支持 index scan sample method , 对应table sample, 这个是索引扫描的随机采样功能.

• • 例如在branch层随机选择leaf page.