@willwen
这是个非常棒的功能！

@a591826944 +10086

@20150517 跟那个没关系……就是pg在获取lastinsertid的时候一定要指定seq完整名称。

@wusibacg
google、bing

select * from articles where article_id in (select distinct(article_id) from tags where tags in ('tag1','tag2','tag3')) limit n

按照这个思路的话不只是创建文件了，创建之前要检查是否有权限，是否有重名文件，是否可以被创建，创建失败的异常处理……

国内现在对在线支付已经管的特别严了，总之，对..有利的事管的都特别严。

@zhyu [:cry:]

@mywaiting
感觉PG就是缺少一些类似mysql那样非常方便的运维工具，比如mysql-proxy（起码我在生产环境使用的没发现过问题和性能损耗）、Fabric等。而不像Pgpool，用了还不如不用……而且好像除此之外也没有什么成熟的工具，还有就是所有架构级设计都依赖sql func，对程序员来说不够透明。搞个Replication要半天时间……
如果pg可以再进化对前段真正的透明了，那我会爱死他的。

最后再提一个，pg对嵌入式设备支持不够友好。

@Mac

DMZ主机

不是有backup么

换PostgreSQL :)

Bing输入法路过，有木有跟我一样的……

@ivyshark
我也去看看es哈哈。如果对距离不敏感其实geohash也是个不错的方案。

@omegaga
欢迎一起分析

@iloahz yeah

@ivanlw
主要是不想用多套解决方案，比如库里更新一下，es更新一下，一个异常，pg没更新，es反倒更新成功了……担心这个

@zado
数据库中存储了1000w个point（经纬度坐标点，x,y 比如：113.846686,34.615693）。
指定一个point，比如112.846686,31.615693，获取这个点附近N公里内的所有点，需要将这个点与数据库中已有的所有点进行距离计算，然后按照距离排序，然后取出范围内的，最后返回。0.0019s已经很快了。


*关于mongodb，可能是我的配置有误（实际上我没做任何配置，启动命令：mongod --fork --dbpath /data/mongo --logpath /dev/null），按照对mongodb的理解，没理由这么慢。