l_tables where relname='test_8000';
? ? ? ? ? ? ? now ? ? ? ? ? ? ?|?column?
-------------------------------+-----------
2015-10-0819:06:37.951332+08|221045069
(1 row)
?
postgres=# select now(),n_tup_upd+n_tup_hot_upd frompg_stat_all_tables where relname='test_8000';
? ? ? ? ? ? ?now ? ? ? ? ? ? ?|?column?
------------------------------+-----------
2015-10-0819:07:46.46325+08|222879057
(1 row)
?
postgres=# select timestamptz '2015-10-0819:07:46.46325+08' - timestamptz '2015-10-08 19:06:37.951332+08';
?column?
-----------------
00:01:08.511918
(1 row)
?
postgres=# select 222879057-221045069;
?column?
----------
1833988
(1 row)
?
postgres=# select 1833988/68.5;
?column?
--------------------
26773.547445255474
(1 row)
?
模拟结果，相比不排队，有1倍以上的性能提升。 ?
TOP
top-19:09:37 up 119 days, ?3:59, ?2 users, ?load average:0.96,0.98,1.01
Tasks:8872 total, ? 5running,8866 sleeping, ? 1stopped, ? 0zombie
Cpu(s): ?5.3%us, ?0.8%sy, ?0.0%ni,93.9%id, ?0.0%wa, ?0.0%hi, ?0.0%si, ?0.0%st
Mem: ?132124976k total,118066688k used,14058288k free, ? 316752k buffers
Swap: ?2097144k total, ? ? ?148k used, 2096996k free,63702028k cached
?
advisory lock是PG提供的一种轻量级的面向用户的锁（当然比LWLOCK是要重的），我之前在秒杀场景的优化中也有叙述，可以达到每秒处理19万次的单条记录更新请求的性能，并且保持1毫秒以内的RT。
?
把这种优化思路加入到PostgreSQL的内核中是比较靠谱的，最终实现的效果会和Oracle的shared server非常类似。
?
阿里云PG内核组的小鲜肉和老腊肉们，优化开始搞起吧。
?
在没有优化前，还是使用pgbouncer这种连接池吧。