【问题标题】:PostgreSQL function execution plan cache principlePostgreSQL函数执行计划缓存原理
【发布时间】:2017-10-10 23:33:36
【问题描述】:

假设我有 2 个函数使用第三个函数。假设 get_company(user_id) 和 get_location(user_id) 使用了 check_permission(user_id) 函数。

执行计划缓存如何工作?我的意思是它会为 check_permission 和 get_company 函数制定单独的执行计划,还是为 get_company 制定一个计划?如果分别为 get_company 和 get_location 构建执行计划,即使它们都使用 check_permission 函数,执行计划也有可能更有效。

【问题讨论】:

标签: postgresql sql-execution-plan


【解决方案1】:

“视情况而定”。

它可以做一个或两个。

如果check_permission 是满足内联要求的LANGUAGE sql 函数,并且get_company 和/或get_location 也是LANGUAGE sql 或将其用作非平凡查询的一部分,它可能会被内联并计划了两次,每个调用者一次,作为调用查询的一部分。

否则,它通常会在任何一个调用者第一次调用时计划一次。

顺便说一句,在实际情况下,请考虑使用视图而不是函数。它们更有效率,并为规划者提供更多选择。但是如果他们需要SECURITY_BARRIER 视图来防止信息泄露,那么好处就更少了。

我想知道如果您专注于计划时间而没有(就您所展示的)研究计划时间实际上影响了您的绩效,是否会犯一个真正的错误。而且您似乎没有考虑通过 fmgr 和 plpgsql 过程处理程序等与原始查询进行工作的显着开销,并将其与计划成本进行权衡。我强烈建议您至少在确保您在整个应用程序中以最佳方式使用准备好的语句之前不要进一步追求这一点。然后衡量相对成本,您的工作量

【讨论】:

  • 据我所知,视图不会缓存其执行计划。
  • 视图不会,但查询会,包括包含视图的查询。总体而言,与通过 fmgr 接口进行函数调用相比,您往往会获得更好的结果,除非您的函数有一个 非常 复杂的查询计划,该计划实际上执行起来也非常便宜,而且永远不会显着受益于内联。
  • 查询是否缓存了他们的执行计划?谢谢,很高兴知道。它给了我更多的问题。请看看我的其他问题here
  • 我认为 plpgsql 中的函数会缓存查询计划。 Ad-hoc SQL 不会,除非您明确使用准备好的查询。 here
  • 是的,没错。但如果你甚至在考虑这样的事情,大概你已经在使用准备好的语句了。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2012-02-18
  • 2012-06-19
  • 2015-04-30
  • 2011-03-06
  • 2021-07-20
  • 1970-01-01
相关资源
最近更新 更多