On Fri, Apr 19, 2019 at 1:17 PM John Naylor <john.naylor@2ndquadrant.com> wrote:
> On Fri, Apr 19, 2019 at 10:38 AM Amit Kapila <amit.kapila16@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