On Fri, Apr 19, 2019 at 1:17 PM John Naylor <john.nay...@2ndquadrant.com> wrote: > On Fri, Apr 19, 2019 at 10:38 AM Amit Kapila <amit.kapil...@gmail.com> wrote: > > > > I think if we go this route, then > > we might need to revisit it in the future to optimize it, but maybe > > that is the best alternative as of now. > > It's a much lighter-weight API, which has that much going for it. > I have a draft implementation, which I can share if it comes to that > -- it needs some more thought and polish first. >
I understand that it is lighter-weight API, but OTOH, it will be less efficient as well. Also, the consensus seems to be that we should move this to relcache. > > I am thinking that we should at least give it a try to move the map to > > rel cache level to see how easy or difficult it is and also let's wait > > for a day or two to see if Andres/Tom has to say anything about this > > or on the response by me above to improve the current patch. > > Since we have a definite timeline, I'm okay with that, although I'm > afraid I'm not quite knowledgeable enough to help much with the > relcache piece. > Okay, I can try to help. I think you can start by looking at RelationData members (for ex. see how we cache index's metapage in rd_amcache) and study a bit about routines in relcache.h. -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com