我正在努力优化我的功能
SELECT map.get_near_link(a.X, a.Y, a.azimuth)
FROM traffic.avl;
第一次17赛格
Total query runtime: 17188 ms.
801 rows retrieved.
第二次11赛格
Total query runtime: 11406 ms.
801 rows retrieved.
我猜有某种缓存在幕后进行优化.
我正在努力优化我的功能
SELECT map.get_near_link(a.X, a.Y, a.azimuth)
FROM traffic.avl;
第一次17赛格
Total query runtime: 17188 ms.
801 rows retrieved.
第二次11赛格
Total query runtime: 11406 ms.
801 rows retrieved.
我猜有某种缓存在幕后进行优化.
PostgreSQL没有"缓存"优化，即查询结果缓存.
它会缓存最近在shared_buffers中读取的表块，但对于大多数安装来说，这只会产生很小的影响.主缓存是操作系统的磁盘读缓存.有关更多信息，请参阅:
See and clear Postgres caches/buffers?
在我看来，你的系统有合理数量的RAM和快速的CPU，但磁盘速度非常慢.因此，只命中操作系统磁盘缓存的查询速度非常快，但进入磁盘的查询需要几秒钟才能读取数据.所以缓存效应非常强.
你应该回答你的问题.try 使用几个不同的输入值，直到得到一个较慢的值.比较计划.
如果计划是一样的，很可能就是这样.
如果计划不同，您可能遇到了这样一种情况:查询计划器根据表统计数据的变化做出错误的 Select .增加感兴趣的列的统计目标可能会有所帮助(请参阅手册).如果你有不同的计划，并且遇到困难/需要帮助，请随时在dba上发布新问题.斯塔克交换.com提供详细信息.