Re: Unhappy about API changes in the no-fsm-for-small-rels patch

From: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
To: John Naylor <john(dot)naylor(at)2ndquadrant(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andres Freund <andres(at)anarazel(dot)de>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Unhappy about API changes in the no-fsm-for-small-rels patch
Date: 2019-04-22 13:19:44
Message-ID: CAA4eK1Lp0yPBCdTGd57UMCbP3V6VggEXdfVmOupM=_6_Oz-_TQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Apr 19, 2019 at 2:46 PM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
>
>
> > > 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.
>

Attached is a hacky and work-in-progress patch to move fsm map to
relcache. This will give you some idea. I think we need to see if
there is a need to invalidate the relcache due to this patch. I think
some other comments of Andres also need to be addressed, see if you
can attempt to fix some of them.

--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com

Attachment Content-Type Size
store_local_map_relcache_v1.patch application/octet-stream 12.6 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David Rowley 2019-04-22 13:27:00 Re: display of variables in EXPLAIN VERBOSE
Previous Message David Rowley 2019-04-22 13:12:16 Re: Runtime pruning problem