Re: Cached/global query plans, autopreparation

Any idea on how feasible it would be as an extention or is the work too
central to abstract that way?

<http://visionlink.org/> Chet Henry
Senior Software Developer - Dev Ops Liaison
VisionLink, Inc.
3101 Iris Ave, Ste 240
Boulder, CO 80301
henry(at)visionlink(dot)org

Site <http://visionlink.org/> | Blog <http://www.visionlinkblog.org/> | Join
Our Team <http://visionlink.org/visionlink-employment-and-careers> | Try a
Demo <http://visionlink.org/demo>
[image: Twitter] <https://twitter.com/VisionLink> [image: Pinterest]
<https://www.pinterest.com/VisionLink/> [image: Facebook]
<https://www.facebook.com/VisionLink.CommunityOS?ref=tn_tnmn> [image:
LinkedIn]
<https://www.linkedin.com/company/71505?trk=tyah&trkInfo=tarId%3A1409768061636%2Ctas%3Avisionlink%2Cidx%3A1-1-1>
[image: YouTube]
<https://www.youtube.com/channel/UCOKWyxX0x68fc2JUwhucw6w>

On Wed, Feb 14, 2018 at 2:19 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Andres Freund <andres(at)anarazel(dot)de> writes:
> > On 2018-02-13 09:13:09 -0800, Shay Rojansky wrote:
> >> Was wondering if anyone has a reaction to my email below about statement
> >> preparation, was it too long? :)
>
> > Well, the issue is that implementing this is a major piece of work. This
> > post doesn't offer either resources nor a simpler way to do so. There's
> > no huge debate about the benefit of having a global plan cache, so I'm
> > not that surprised there's not a huge debate about a post arguing that
> > we should have one.
>
> Actually, I'm pretty darn skeptical about the value of such a cache for
> most use-cases. But as long as it can be turned off and doesn't leave
> residual overhead nor massive added code cruft, I won't stand in the way
> of someone else investing their time in it.
>
> In any case, as you say, it's moot until somebody steps up to do it.
>
> regards, tom lane
>
>