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 he...@visionlink.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 <t...@sss.pgh.pa.us> wrote: > Andres Freund <and...@anarazel.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 > >
