Re: Unhappy about API changes in the no-fsm-for-small-rels patch
От | Amit Kapila |
---|---|
Тема | Re: Unhappy about API changes in the no-fsm-for-small-rels patch |
Дата | |
Msg-id | CAA4eK1KsBYKTmHihv1BVU__1yxkb6uk5pDvhSLgiaryoaQzj=A@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Unhappy about API changes in the no-fsm-for-small-rels patch (John Naylor <john.naylor@2ndquadrant.com>) |
Ответы |
Re: Unhappy about API changes in the no-fsm-for-small-rels patch
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: