数据库 PostgreSQL 的异步操作接口，以及 Ruby 中对应实现
我们团队一直在用 padrino 框架做开发，数据库操作，是用 sequel 这个轻量级库。 在开发中遇到数据 IO 的瓶颈，就想把数据库操作改为异步的，来提升代码性能。
原以为 sequel 默认都是同步方式来操作数据库，但看了源码和说明，才发现 sequel 默认都是在用异步接口：
于是就扒了一下 sequel 依赖的那些库：
libpq 本身，确实支持同步和异步两种操作方式：
http://www.postgresql.org/docs/current/static/libpq-async.html
一个数据库连接，就是一条 TCP 连接，libpq 是客户端，Pg 是服务端，
同步方式，libpq 将指令发送到 Pg，Pg 指令执行完成，将结果发回，libpq 收到结果后，才继续执行下面的代码：
下面看看 ruby-pg：https://github.com/ged/ruby-pg
ruby-pg 对 Pg 的操作，是依赖 libpq 实现的，其中也包含异步操作接口。
但是，经过 ruby-pg 的封装，异步接口，已经和同步效果一样，看代码：
https://github.com/ged/ruby-pg/blob/master/ext/pg_connection.c#L3034
也就是说，想要在 ruby 实现对 Pg 的异步操作数据库，ruby-pg 本身不支持。 还是要自己实现个 libpq 的拓展，就把 ruby-pg 中那个轮询的循环去掉就行。
#2 楼 @jimrokliu 在 nodejs 这种平台，回调结构很自然。 但要在 ruby，尤其是 MRI 上实现回调，比较折腾，还是算了。
应该说 pg 对异步支持不太好，然后只能这样实现了。pgconn_send_query 只是返回是否 dispatch 成功，After successfully calling PQsendQuery, call PQgetResult ** one or more times ** to obtain the results.
#5 楼 @fake_whythelukystiff libpq 提供的是基本的异步支持，可以给开发者提供多一种选择，足够了。 只不过，在 ruby-pg 中，把异步接口实现成同步了，容易给上层开发者带来误解。 sequel 的维护者，就认为 async_exec 不会阻塞 ruby 解释器。 nodejs 这种回调优先的平台，在 pg 接口：node-postgres 的实现中，都是用 libpq 的异步函数。
#6 楼 @ChrisLoong 这个问题今天老在我心头萦绕不绝...我觉得即便专门用 PQsendpreapred 这些专门用于异步的函数都避免不了阻塞。如果你用 ruby 的话，会怎么实现这个异步？
#8 楼 @fake_whythelukystiff libpq 里面提供的异步函数，就是方便客户端程序，在独立的线程上阻塞等待结果，而不影响主线程。 伪代码：
def async_exec(sql)
Thread.new do
conn.PQsendQuery(sql)
while true
res = PQgetResult(conn)
if res
yield res
break
end
end
end
end
async_exec("select...") {|res| #process result }
nodejs 里面的回调，主要就是靠 libuv 这个库实现的，就是把 IO 的等待，都放在单独的线程池里面阻塞，主线程还是可以继续处理 request。
ruby 的 web 应用里，都是单进程执行，一个 IO 阻塞了，那就无法处理后面的 request。
我们为了产品稳固，涉及这种耗时操作的，都放队列去执行了，不会去用线程，否则带来的问题更多。
ruby 里面也有个libuv 的拓展，但是如果要用这个库做东西，还不如直接用 nodejs 
。
#10 楼 @hz_qiuyuanxin 有些 sql 执行太慢，导致 app 处理请求的性能下降，还没时间做 DB 层面优化， 我们就是用队列来临时解决了。
SQL执行太慢，对应的表的数据大概有多大，其增长速度有多快？不能先简单地通过索引的方式来优化执行性能吗？
在这里问题的本质就是在当前的状态下，做这种事情本身就需要那么多时间，除非你在同一个进程里，有好几个事情可以并发做，这样才有可能带来性能的提升，但是响应最慢的事情也决定了整个进程的响应的时间。
所以要么优化 SQL 执行，可以用空间来换取时间；要么将一些事情放在 background job 里面去做；要么...，哈，我也不知道了。
#13 楼 @hz_qiuyuanxin 数据规模不大，电商的业务逻辑，略烦，表很多，数据库函数很长...等产品功能完善了，再慢慢优化吧。
