我想使用计划缓存来节省计划器成本,因为 OCRA/Legacy 优化器将花费数千万秒。
我认为会话级别的greenplum缓存查询计划,当会话结束或其他会话无法共享分析的计划时。更重要的是,我们不能一直保持会话,因为 gp 系统在 TCP 连接断开之前不会释放资源。
大多数主要的数据库缓存计划在第一次运行后,并使用该 corss 连接。
那么,是否有任何开关可以打开查询计划缓存交叉连接器?我可以在会话中看到,客户端计时统计与规划器给出的“总时间”不匹配?
我想使用计划缓存来节省计划器成本,因为 OCRA/Legacy 优化器将花费数千万秒。
我认为会话级别的greenplum缓存查询计划,当会话结束或其他会话无法共享分析的计划时。更重要的是,我们不能一直保持会话,因为 gp 系统在 TCP 连接断开之前不会释放资源。
大多数主要的数据库缓存计划在第一次运行后,并使用该 corss 连接。
那么,是否有任何开关可以打开查询计划缓存交叉连接器?我可以在会话中看到,客户端计时统计与规划器给出的“总时间”不匹配?
Postgres 也可以缓存计划,这是基于每个会话的,一旦会话结束,缓存的计划就会被丢弃。这可能很难优化/分析,但通常不太重要,除非您正在执行的查询非常复杂和/或有很多重复的查询。
该文档很好地详细解释了这些内容。我们可以查询 pg_prepared_statements 来查看缓存了什么。请注意,它不能跨会话使用,并且仅对当前会话可见。
当用户启动与 Greenplum 数据库的会话并发出查询时,系统会在每个段上创建工作进程组或“帮派”来完成工作。工作完成后,除了由 gp_cached_segworkers_threshold 参数设置的缓存数字外,段工作进程将被销毁。
较低的设置可以节省分段主机上的系统资源,但较高的设置可能会提高想要连续发出许多复杂查询的高级用户的性能。
另请参阅 gp_max_local_distributed_cache。
显然,您缓存的越多,可用于其他连接和查询的内存就越少。如果您只托管几个运行并发查询的高级用户,这可能没什么大不了的……但您可能需要相应地调整您的 gp_vmem_protect_limit。
澄清一下:在 gp_vmem_idle_resource_timeout 之后释放段资源。只有主会话将保留,直到 TCP 连接断开。