digoal
2017-10-17
PostgreSQL , Greenplum , TODO
https://wiki.postgresql.org/wiki/Todo
quorum based sync replication + client driver auto failover
此法，可以用于sharding库的中间层库的扩展。
a, b, c, d。
a为主库，b,c,d为从库。 a,b,c,d都作为中间库，使用postgres_fdw或其他fdw来做sharding。
同步复制自动降级，自动锁定（设置降级后的延迟阈值）。
阈值可配置。
半同步，HANG N s 自动降级为异步。
延迟N秒或N bytes，或N个事务后，再次hang，确保丢失在允许范围内。
cache后，再升级为同步模式。
此模式可以保证丢失在0到N的范围内。
增加一个同步模式，remote_delay，当SYNC standby节点的WAL接收延迟低于这个值时，使用local的提交方式，用户COMMIT时，不进入等待队列。
例如remote_delay=8KB
那么当延迟低于8KB时，COMMIT或ROLLBACK不需要等待wal发送给备库，也就是说不需要进入sleep状态，本地REDO落盘后就提交。
批量入库FEATURE
5个开关 ：
是否允许自动回滚，
批量提交QUERY数，
批量提交tuple影响数，
idle in transaction 超时参数
是否开启自动的savepoint
自动分批提交特性：
如果没有在事务中，则自动开启BEGIN
到达阈值自动提交，并自动开启BEGIN
允许用户选择是否自动回滚
需要注意snapshot too old目前不处理写事务过旧。
需要注意9.6以前的版本，长事务可能导致膨胀。
应用场景：
业务有大量的写入，
业务不想改SQL，就是单条单条插入
在同步多副本环境中特别有效。
效果与 sync=off 类似
但是记录批次可控，同时用户可感知，自动回滚到前一个savepoint。
安全性比sync=off高。
目前同步复制，事务提交时在一个队列中等待WAL SENDER获取到的RMT LSN进行释放。 导致大量的MUTEX锁，同时很多进程的等待可能是无效的。
建议改成进程自己去询问RMT的LSN。
采用N个预先建立的primary到standby(s)的连接，根据主节点backend process PID取模，自动选择对应的链路去询问。
询问的LSN，分为几个(wal receiver(to buffer), wal write, wal flush ,wal apply)，询问到的LSN同时也通知给其他进程，其他进程也一样，自己去询问，同时接受别人询问的结果，一伙人去询问，可能效率更高。
进程根据不同的级别，选择需要比较的COMMIT LSN与RMT LSN，进行释放。
1、允许用户设置表级vacuum 保留版本数，延迟VACUUM，同时延迟清理PG_XLOG，PG_CLOG。
用户指定falshback的时间，查询当时的表快照。
指定时间时，根据扫描到的XMIN或XMAX，在PG_XLOG中判断事务的提交时间，以及pg_clog中的事务结束状态，判断对用户是否可见。
如果事务提交时间早于FLASHBACK时间，并且PG_CLOG事务结束状态为提交，则对用户可见。
2、postgresql, 支持flashback, 例如postgresql 主备切换时，老的主库在没有配置recovery.conf时启动并有写入，导致分裂。使用flashback可以快速回到上一个时间线。
使用pg_rewind可以实现同样功能。内部实现可以在启动后记录若干个变更的UNDO，从而实现可以回退。
根据场景自动选择gin\rum索引的需求。
3. PostgreSQL , paralle append + 外部表 + pushdown，可以实现sharding 架构下的并发计算。（例如求SUM,AVG,COUNG,MIN,MAX等，不过针对外部表的parallel append内核层面还没有支持好，需要CUSTOM SCAN）
《PostgreSQL 店铺运营实践 - JSON[]数组 内部标签数据等值、范围检索100倍+加速示例》
分区索引。
arr >>= ? and arr <<=?
使用新的操作符代替>=, <=，实现元素的区间扫描。
虚拟索引，查看执行计划的变化，有多少提升。
PPAS 10已支持。
《自动选择正确索引访问接口(btree,hash,gin,gist,sp-gist,brin,bitmap...)的方法》
目前通过cte递归来支持
全局索引，以及全局分区索引。
目前大表扫描，超过四分之一SHARED BUFFER的表，会设置FLAG，分批读取，并优先刷出SHARED BUFFER，防止扫描大表时SHARED BUFFER的抖动。
Oracle 18c 已支持
\set suffix random(1,128)
\set id random(1,10000000)
select * from tbl:suffix where id=:id;
pg的存储过程接口非常丰富，用到的用户也非常多，版本控制的功能非常重要。
http://blog.csdn.net/huang_xw/article/details/6402396
1 grouping()
参数只有一个，而且必须为group by中出现的某一列，表示结果集的一行是否对该列做了grouping。对于对该列做了grouping的行而言，grouping()=0，反之为1；
2 grouping_id()
参数可以是多个，但必须为group by中出现的列。Grouping_id()的返回值其实就是参数中的每列的grouping()值的二进制向量，例如如果grouping(A)=1，grouping(B)=0，则grouping_id(A,B)的返回值就是二进制的10，转成10进制就是2。
3 group_id()
无参数。见上面的说明3），group by对某些列的集合会进行重复的grouping，而实际上绝大多数情况下对结果集中的这些重复行是不需要的，那就必须有办法剔出这些重复grouping的行。当结果集中有n条重复grouping而形成的行时，每行的group_id()分别是0,1,…,n，这样我们在条件中加入一个group_id()<1就可以剔出这些重复grouping的行了。
12. grant select on table 可以直接扣减 revoke select on table (column)。而不是只能grant select on table (column)来控制列的查询权限。
目前只能使用逻辑订阅支持，建议可以UDF化，通过UDF可以控制TABLE放到对应SLOT中。
pgsql的数据实时同步到elastic
https://developer.atlassian.com/blog/2015/02/realtime-requests-psql-elasticsearch/
https://github.com/jprante/elasticsearch-jdbc
pgsql直接访问elastic的数据
https://github.com/Mikulas/pg-es-fdw
https://www.elastic.co/products/kibana
人才方向，可视化，GIS
https://wiki.postgresql.org/wiki/Development_information
https://postgrespro.com/roadmap/
https://wiki.postgresql.org/wiki/NTT_roadmap
range[] - range[] 减
range[] + range[] 加
range[] & range[] 相交
| range[] , 合并相邻或重叠的元素
减少交互次数，直接在QUERY中包含begin或END，ROLLBACK的包。
减少交互次数。
例如
select /*+ begin */ x from tbl;
自动开启事务
update /+ end */ t set xx=xx where xx;
update /+ commit */ t set xx=xx where xx;
自动提交当前事务
update /*+ rollback */ t set xx=xx where xx;
自动回滚当前事务
通过定义规则，实现对测试流量的分流。
目前类似双十一或者其他公司在搞大促，或者对系统进行压测时，会模拟测试请求，这些请求不应该直接写入生产表。
可以写到影子表，例如TBL对应的影子表TBL_TEST。
PG可以根据客户端IP，客户端端口，application_name判断客户端是否属于测试来源。
用户可以配置规则，将属于测试来源的数据，在query rewrite这一层，把SQL改写掉，TBL_TEST替代TBL。
内核层面的连接池。
连接池考虑多个分组，用户可以自定义使用哪个分组，或者默认根据QUERY的读写特性区分分组，或者根据QUERY的时长区分分组。
目前pg_hba.conf仅支持角色名，库名。
但是不能区分角色是普通用户还是超级用户。
增加这个功能可以用来控制更细粒度的权限。
例如禁止超级用户从远程登录。(现有的方法，把所有超级用户列一遍，但是当用户权限变更（例如从超级用户变成了普通用户）后，PG_HBA.CONF并不会变更。)
syscache
relcache
buffer
read uncommitted 隔离级别
从数据文件直接读取数据文件的内容。类似灾难恢复
[思路]
一种负载策略。
读负载均衡、或多master的场景，客户端(最终客户端或proxy)选择就近节点。
例如多机房的场景，通过IP地址判断先从哪个节点读。
或者根据配置的节点顺序进行，直到取到正常节点为止(pg-jdbc目前是这种方式)。
目前PG所有日志都打印在一起，不利于日志分析。
建议将审计日志、错误日志、慢SQL日志(包括auto_explain的)、其他日志分开成4个文件打印。
自动校准cost因子，让实例得到最准确的执行计划
支持不同业务形态的表，采用不同的块大小。
默认每次EXTEND 1个BLOCK，批量导入时性能有提升空间。
《PostgreSQL 单表并行bulkload的extend file lock 冲突问题解决》
PG如果能将插入这块的消息协议改进一下也许性能能提高比较多，将目前的 ESES..ES 改为 EEE...S 就好了。这样就可以实现类似于批量插入了。
截断头尾百分比后输出聚合值。类似的应用场景有排除噪点、干扰数据后的聚合。
例如统计tps的平均值，方差，标准差。但是由于一些干扰因素可能导致测试TPS时造成了一些干扰，使用这种方法可以过滤掉一些干扰数据。
http://api.pgxn.org/src/trimmed_aggregates/
允许用户选择需要精确count还是评估COUNT
结合pg_class.reltuples
结合sample语法，输出采样
数据同步模块
37. postgresql, pg_stat_all_tables, 建议添加autovacuum, auto analyze, analyze, vacuum等存储为数组，记录最近N次的操作统计信息，包括每次扫描了多少BLOCK，产生了多少DIRTY PAGE等等。
便于突发的IO或CPU的排错。 目前只记录最后一次，而且统计信息只能到LOG里面翻看，不够便捷。
-[ RECORD 57 ]------+---------------------------------------
relid | 16794
schemaname | public
relname | xxx
seq_scan | 0
seq_tup_read | 0
idx_scan | 7878
idx_tup_fetch | 29897
n_tup_ins | 48337
n_tup_upd | 0
n_tup_del | 0
n_tup_hot_upd | 0
n_live_tup | 765193
n_dead_tup | 0
n_mod_since_analyze | 13404
last_vacuum |
last_autovacuum | 2018-01-16 17:42:57.694793+08
last_analyze |
last_autoanalyze | 2018-01-13 09:13:02.457322+08
vacuum_count | 0
autovacuum_count | 1
analyze_count | 0
autoanalyze_count | 1
39. PostgreSQL, GPDB , jsonbd 一种内置压缩能力的JSON类型，实际上数据库内核也可以在数组、全文检索等其他多值类型上增加类似的压缩功能（相当于内置的数据字典能力），将字典化这个工作转嫁给数据库来实现。
https://github.com/postgrespro/jsonbd
CREATE EXTENSION jsonbd;
CREATE TABLE t(a JSONB COMPRESSION jsonbd);
用途，在多副本的情况下，HA切换时，保证不出现脑裂。
pg_catalog | pg_wal_replay_pause | void | | normal
pg_catalog | pg_wal_replay_resume | void | | normal
citus, 元数据 2PC，同时要求每个节点的SLAVE，必须同步接收到DDL。
保证元数据的全局一致性。
当是企业中有多个数据库时，需要一个可以管理多个实例的软件。
例如将问题优先暴露。
目前PG支持select xxx for update skip locked , nowait.
但是不支持dml直接使用skip locked或者nowait
不利于低延迟的同类需求，需要发多次QUERY，开启事务来支持。
考虑添加直接的 update | delete skip locked, nowait 支持。
例如采用索引扫描返回很多条记录假设100万，用户需要在这100万随机挑选10000条，排序输出TOP -K。
常用于大量数据搜索，例如推荐引擎。
《PostgreSQL DaaS设计注意 - schema与database的抉择》
《PostgreSQL 备库apply延迟(delay)原理分析与诊断》
避免多重BUFFER
主备异常切换时，老主库可能有未同步到备库的WAL，出现时间线分歧。但是在未来可能被demote为备库，实际上已经不能接上备库，如果1 MIN内再次发生HA，会导致切换到不该切换的库。
加一个函数，防止脑裂(主备由于时间线错乱不可相互复制状态)，在备库的角色执行，判断当前主备是否处于脑裂状态。
脑裂时，不能主动切换到脑裂的备库。（人为介入，如果主库不可恢复，可能需要人为修复）
目前需要从LOG中判断
2018-05-04 11:29:55.524 CST,,,28551,,5aebd38b.6f87,20,,2018-05-04 11:29:15 CST,,0,LOG,00000,"restarted WAL streaming at 118/EA000000 on timeline 5",,,,,,,,"WalReceiverMain, walreceiver.c:400",""
2018-05-04 11:29:55.534 CST,,,28551,,5aebd38b.6f87,21,,2018-05-04 11:29:15 CST,,0,LOG,00000,"replication terminated by primary server","End of WAL reached on timeline 5 at 118/EABAA6D0.",,,,,,,"WalReceiverMain, walreceiver.c:467",""
2018-05-04 11:29:55.535 CST,,,28547,,5aebd38b.6f83,14,,2018-05-04 11:29:15 CST,1/0,0,LOG,00000,"new timeline 6 forked off current database system timeline 5 before current recovery point 118/EABCA368",,,,,,,,"rescanLatestTimeLine, xlog.c:4347",""
以下为已有的判断依据，接收到的WAL小于REPLAY的WAL位置。说明本地库在作为主库角色时，有WAL没有同步给上游，所以出现接收到的WAL小于REPLAY的WAL位置。
postgres=# select pg_last_wal_replay_lsn();
pg_last_wal_replay_lsn
------------------------
118/EABCA368
(1 row)
postgres=# select pg_last_wal_receive_lsn();
pg_last_wal_receive_lsn
-------------------------
118/EA000000
(1 row)
pg_last_wal_receive_lsn小于pg_last_wal_replay_lsn，或pg_last_wal_receive_lsn 为 NULL，都可以判断为脑裂。
支持cluster ， 数据INSERT时动态聚集.
数据按 segment组织，SEGMENT 内 尽量的保持按cluster id值聚集。
prefetch 效果好 ，范围扫描，效率提升
DB2, fsm，列表结构，并发写存问题
fsm 打散，多个，随机挑选，降低写入冲突
目前SLOT会导致主库不清理备库需要的垃圾版本，导致膨胀，CPU飙升等问题。
改良，把这块的功能去掉，这块的功能还是需要feed back开关来控制。
目前PG的一个DB在一个TBS中对应一个目录，如果这个DB在表空间下很多对象，可能打爆文件系统的INODE INDEX上限。
建议，加一层目录，改进pg_filemap，比如按TABLE OID HASH一层。这样可以减少文件系统的INODE INDEX打爆。
《如何在CentOS 6.x x64系统中创建超过16TB的ext4文件系统》
1、读写磁盘吞吐快照区间统计，区分索引，表，垃圾回收，FREEZE，AUTOANALYZE。分类统计。
2、锁等待时长快照区间统计，区分锁粒度，下钻到对象。
例如一个范围类型的数组，不需要展开数据，即可对齐进行索引的包含检索。
类似于range的倒排+GIST索引。
GIS类型的统计信息不多，评估不准确。
postgres=# select * from pg_stats where tablename='test' and attname='pos';
schemaname | tablename | attname | inherited | null_frac | avg_width | n_distinct | most_common_vals | most_common_freqs | histogram_bounds | correlation | most_common_elems | most_common_elem_freqs | elem_count_histogram
------------+-----------+---------+-----------+-----------+-----------+------------+------------------+-------------------+------------------+-------------+-------------------+------------------------+----------------------
public | test | pos | f | 0 | 32 | -1 | | | | | | |
(1 row)
postgres=# explain analyze select * from test where st_contains(st_setsrid(st_makebox2d(st_makepoint(119,60), st_makepoint(122,71)), 4326) , pos);
QUERY PLAN
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Gather (cost=0.00..2815576.91 rows=10033 width=553) (actual time=1.028..11177.961 rows=30100000 loops=1)
Workers Planned: 12
Workers Launched: 12
-> Parallel Seq Scan on test (cost=0.00..2815576.91 rows=836 width=553) (actual time=0.048..2786.635 rows=2315385 loops=13)
Filter: (('0103000020E610000001000000050000000000000000C05D400000000000004E400000000000C05D400000000000C051400000000000805E400000000000C051400000000000805E400000000000004E400000000000C05D400000000000004E40'::geometry ~ pos) AND
_st_contains('0103000020E610000001000000050000000000000000C05D400000000000004E400000000000C05D400000000000C051400000000000805E400000000000C051400000000000805E400000000000004E400000000000C05D400000000000004E40'::geometry, pos))
Planning time: 0.189 ms
Execution time: 13554.917 ms
(7 rows)
《PostgreSQL 空间类型统计信息不准确导致SQL执行计划不准(包含、相交查询)的优化实践》
重启实例时，会堵塞所有新建连接，然后开始执行SHUTDOWN CHECKPOINT，如果此时数据库SHARED BUFFER里面的DIRTY PAGE很多，会导致shutdown时间很长，影响业务的时间也比较长。
改进建议：
1、先执行checkpoint，此时不影响业务。
2、执行完CKPT后，进入原有的SHUTDOWN流程，堵塞所有新建连接，然后开始执行SHUTDOWN CHECKPOINT。
3、由于第一步已经执行了CKPT，所以基本上SHARED BUFFER里面的DIRTY PAGE已经很少了，第二步执行shutdown checkpoint时，会很快，影响业务（堵塞连接）的时间很短。
当数据库异常停库，再次启动时。又或者由于进程CRASH后自动重启时。需要进入恢复模式，恢复完成后，数据库才能正常交互。
在启动过程中，正在恢复时，如果此时连接数据库，会报错如下：
the database system is starting up
用户只看这个信息，并不知道数据库还要启动多久，现在已经恢复到什么状态了？
内核层面可以稍作改进，报错时，同时输出正在恢复的WAL位点，以及距离最后一个文件的WAL位点差多少MB没有恢复。这样用户大概就还知道还需要多久。
《PostgreSQL 恢复模式错误日志增强 - 提供正在恢复的WAL（XLOG）文件位置》
1、慢SQL记录到表里面。（或者单独的文件存储方便查询）
2、DDL语句记录到表里面(密码相关部分，加密（掩码）显示)。
3、不带条件的DML (delete, update) ， 记录到表里面
4、影响行数超过N（可配置）的DML(update, delete)，记录到表里面。
5、返回结果超过N（可配置）的查询（select） ， 记录到表里面。
cube 支持float4元素，提高INDEX搜索性能。
《PostgreSQL 相似搜索插件介绍大汇总 (cube,rum,pg_trgm,smlar,imgsmlr,pg_similarity) (rum,gin,gist)》
《PostgreSQL 11 相似图像搜索插件 imgsmlr 性能测试与优化 1 - 单机单表 (4亿图像)》
开启full page write，写压测的情况下，checkpoint时性能抖动严重。
找一下原因，改进。
write sensitive
1. mvcc (vacuum, bloat) zheap stable
2. 32 bit xid (freeze)
3. fpw (checkpoint, write sensitive场景性能下降)
4. column store 分析场景
5. mem table
6. sharding
7. multi master
merge join + limit的优化
《PostgreSQL JOIN limit 优化器 成本计算 改进 - mergejoin startup cost 优化》
PostgreSQL recovery 优化
《PostgreSQL WAL replay 加速(datapage preload) - 恢复加速, 备库延迟优化》
schema 支持设置默认表空间。
在schema中创建的对象，如果没有指定TBS，则使用schema指定的默认表空间。
资源限制，资源配额（一个配额周期（时间周期），限制用户、数据库可以扫描的block数、。。。）。
《PostgreSQL 数据库资源限制 + HOOK(limit guc) - 降低攻击伤害、自动SQL优化等》
merge join query rewrite优化。
《PostgreSQL merge join 扫描方法实例细说，以及SQL写法注意 或 内核优化建议 - query rewrite》
一个参数支持多个配置。 根据角色设置不同的参数。
例如当角色是primary时，wal_keep_segments=1000 当前是standby时，wal_keep_segments=0
按需开启binlog，用户勾选数据库、表，开启对应对象的binlog。 数据库自动解析并存储binlog。
oom信号为9,pg无法处理这个信号，oom如果可以改成15来terminate process，可以避免数据库recovery状态，提高稳定性。
gist 索引order by距离，filter 距离范围, limit 时，自动判定filter不满足条件后不再扫描。目前如果遇到满足条件的limit记录数不足，会导致扫描所有索引。性能很差。
《PostgreSQL GiST Order by 距离 + 距离范围判定 + limit 骤变优化与背景原因》
pg支持index scan或者其他除seqscan以外的随机采样方法， 例如select xx from xx where xx return random limit x; 既能走索引， 又能高效率随机访问满足条件的结果。
需求同50
SQL审计接口， paser+stats+explain+rule
代价， 白名单， 黑名单， 学习， where等部位规则。
用户如果要更换DB密码，那么应用层可以做到非常平滑。
https://wiki.postgresql.org/wiki/PGQ_Tutorial
14. 目前GPDB的dml(update, delete)为exclusive lock，相互冲突。增加分布式死锁检测机制，同时将DML的锁降低为row exclusive lock. 解决从冲突问题，提高并发能力。
xid 64 bit
undo storage engine
热插拔存储接口
内置连接池
flashback query
column store
block level compress
sharding improve
native partition improve (performance)
gpu native support
向量计算
只读实例支持mpp, 支持多个实例MPP查询.
block level increment backup
(plugable)transfer database，支持增量
(plugable)transfer table
(plugable)transfer schema
wal wirter parallel , 提升写性能 , 高并发处理吞吐能力
global temp table
memory table
optimizer improve（复杂QUERY优化、机器学习、AP类查询动态根据上一步调整下一步nodeplan）
(AWR) waiting sample statistic improve
statistics activity improve(统计信息：qps, tps, net, iops, insert rows/s, fetch rows/s, delete rows/s, update rows/s)
client driver + auto failover quorum based replication - zero downtime
audit performance improve
checkpoint performance smoothly
quorum based sync replication performance improve 目前PG的wal sender需要等wal落盘才会往wal receiver发送。实际上可以在wal 写入wal buffer就往wal receiver发送，弥补网络的RT。
build-in logical decoding client for continuent sync data to message queue
slot info sync to standby, 目前slot不会同步到standby，如果有基于流复制主从的架构下使用SLOT，切换后SLOT就没了。
统计信息增强，增加多种柱状图，类似ORACLE
skip index scan (支持非驱动列搜索，高速count distinct)
disk quota
job 支持
copy filter
mview performance improve，类似ORACLE
分段 brin
更好的共享、会话级内存管理(work mem, relcache, ...)
global snapshot, 读写分离跨库一致性（一个事务的请求可以被拆到多个实例执行）.
透明读写分离client driver。
pgpool-II improvement
oracle 兼容性
mysql 兼容性
ms sql 兼容性
您的愿望将传达给PG kernel hacker、数据库厂商等, 帮助提高数据库产品质量和功能, 说不定下一个PG版本就有您提出的功能点. 针对非常好的提议，奖励限量版PG文化衫、纪念品、贴纸、PG热门书籍等，奖品丰富，快来许愿。开不开森.
