On Sun, Aug 8, 2021 at 2:52 PM vignesh C <vignesh21@gmail.com> wrote:
>
> On Fri, Aug 6, 2021 at 4:39 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
> >
> > On Fri, Aug 6, 2021 at 2:02 PM vignesh C <vignesh21@gmail.com> wrote:
> > >
> > > On Wed, Aug 4, 2021 at 4:10 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
> > > >
> > > > On Tue, Aug 3, 2021 at 8:38 PM vignesh C <vignesh21@gmail.com> wrote:
> > >
> > > > 6.
> > > > + {PublicationSchemaRelationId, /* PUBLICATIONSCHEMAMAP */
> > > > + PublicationSchemaPsnspcidPspubidIndexId,
> > > > + 2,
> > > > + {
> > > > + Anum_pg_publication_schema_psnspcid,
> > > > + Anum_pg_publication_schema_pspubid,
> > > > + 0,
> > > > + 0
> > > > + },
> > > >
> > > > Why don't we keep pubid as the first column in this index?
> > >
> > > I wanted to keep it similar to PUBLICATIONRELMAP, should we keep it as
> > > it is, thoughts?
> > >
> >
> > Okay, I see your point. I think for PUBLICATIONRELMAP, we need it
> > because it is searched using the only relid in
> > GetRelationPublications, so, similarly, in the patch, you are using
> > schema_oid in GetSchemaPublications, so probably that will help. I was
> > wondering why you haven't directly used the cache in
> > GetSchemaPublications similar to GetRelationPublications?
>
> Both of the approaches work, I was not sure which one is better, If
> the approach in GetRelationPublications is better, I will change it to
> something similar to GetRelationPublications. Thoughts?
>
I think it is better to use the cache as if we don't find the entry in
the cache, then we will anyway search the required entry via sys table
scan, see SearchCatCacheList. I think the point I wanted to ensure was
that a concurrent session won't blow up the entry while we are looking
at it. How is that ensured?
--
With Regards,
Amit Kapila.
