liuguangxuan

换了一台性能比较好的服务器，再加上二次查询的原因，可能内存中有缓存，所以现在比较快，大约 64°*64°的区域，在 6~7 秒左右，老哥还有没有优化的方法？

@beginor #6 老哥，我大概按你的方法测试了一下，分别测试了 st_contains 、st_intersects 、&&在不同索引（ gist,sp-gist ）下的查询情况，并且换了一台服务器。每次测试均重启了服务器。

总体而言，gist 索引性能好于 sp-gist 索引，首次查询 st_intersects 性能比较好，第二次查询&&性能比较好。

测试结果和老哥说的有点儿出入，能不能帮忙解答一下原因，还是我测试的方式不太对？

@nuistzhou #1 如果单看返回条数的话，使用 select count(*)，时间也差不太多。

@nuistzhou #1
@beginor #2
老哥，经纬度索引列，应该是没问题，类型为 geometry(Point)，我用\d tablename ，能查到索引。只是建立索引的时候没有添加编码 4326 ，请问这个影响大吗？

另外可能和我测试环境的配置有关系，我用的是腾讯云 2 核 8G 内存，PostgreSQL 的配置文件保持默认的设置。

提高服务器硬件资源配置是一方面，老哥可否指点一下其它提高查询性能的方法。

@v2eb #17
@dzdh #18 不需要全部都展示出来。

我的需求跟 OP 的有点儿类似，都属于地理空间查询。但是我可能比 OP 多了一些其它的字段属性，比如高度，速度，老哥们可以理解为飞机的轨迹，我不太需要关注每个实时的点，我更关注飞机的整体航迹。然后在地图上快速的从 1 亿个点里面把飞机的整体轨迹筛选出来。老哥们有没有比较快速的办法？

@dzdh #14 老哥，在这里 E 是个什么单位？

另外我用 PostgreSQL+PostGIS 测试了一下，随机在经度（-180°~180°），纬度（-90°~90°）生成 1 亿个点，查询 32°*32°的矩形区域，搜索出来的点数大约为 150 万个，耗时需要 15 分钟。这个属于正常的吗？有没有什么优化手段可以把查询时间降下去？

@adoal #24 感谢老哥回复，有理有据。现在已逐步放弃了打包的想法了。😂

@Chipmunker #18 感谢老哥，发的这个链接，感觉里面思路有点儿清奇，是个办法。

但是我想做的其实就是你说的第一步，“首先按照预设运行平台，使用 cmake 中的 cpack 来生成对应平台的包（ rpm, deb ）”，我想实现的是 cmake 自动能识别平台，比如为 CentOS 或者 Ubuntu ，然后分别达成 rpm 包，或者 deb 包。老哥有没有推荐的教程啊？

@adoal #16 检测发行版的目的：有的用户是 CentOS ，有的是 Ubuntu ，所以有了想检测发行版的想法。最初的想法打包时检测，分别打成不同的包，CentOS 的用户就给 rpm 包，Ubuntu 用户就给 deb 包。

rpm 的 spec 我研究了一下，好像最终是使用 rpmbuild 来打包，debian 的 rules 还没来得及研究。

关于打包目的和在公司的角色：我在公司是开发，因为人手不够，所以兼顾运维、写文档等等。至于公司的 IT 基建环境，可以说为 0 ，没有任何规范，一切都靠自己，所以只能摸索前进。我看到很多开源的工具都提供 rpm 包，就想着这个可能就是发布程序的最佳实践，就想学习一下，然后应用到公司以后发布程序中。

另外没有进过大厂，也不知道大厂的分工，这是我第一次听基建这个词，老哥能否介绍一下大厂的各个部门，以及各个部门的职责。