On Tue, Oct 22, 2019 at 10:53 AM Amit Kapila <amit.kapila16@gmail.com> wrote:
>
> On Tue, Oct 22, 2019 at 10:50 AM Dilip Kumar <dilipbalaut@gmail.com> wrote:
> >
> > On Tue, Oct 22, 2019 at 9:10 AM Amit Kapila <amit.kapila16@gmail.com> wrote:
> > >
> > > On Fri, Oct 18, 2019 at 4:51 PM Dilip Kumar <dilipbalaut@gmail.com> wrote:
> > > >
> > > > I have prepared a first version of the patch. Currently, I am
> > > > performing an empty page deletion for all the cases.
> > > >
> > >
> > > Few comments:
> > > ----------------------
> > > 1.
> > > -/*
> > > - * State kept across vacuum stages.
> > > - */
> > > typedef struct
> > > {
> > > - IndexBulkDeleteResult stats; /* must be first */
> > > + IndexBulkDeleteResult *stats; /* kept across vacuum stages. */
> > >
> > > /*
> > > - * These are used to memorize all internal and empty leaf pages in the 1st
> > > - * vacuum stage. They are used in the 2nd stage, to delete all the empty
> > > - * pages.
> > > + * These are used to memorize all internal and empty leaf pages. They are
> > > + * used for deleting all the empty pages.
> > > */
> > > IntegerSet *internal_page_set;
> > > IntegerSet *empty_leaf_set;
> > >
> > > Now, if we don't want to share the remaining stats across
> > > gistbulkdelete and gistvacuumcleanup, isn't it better to keep the
> > > information of internal and empty leaf pages as part of GistVacState?
> >
> > Basically, only IndexBulkDeleteResult is now shared across the stage
> > so we can move all members to GistVacState and completely get rid of
> > GistBulkDeleteResult?
> >
>
> Yes, something like that would be better. Let's try and see how it comes out.
I have modified as we discussed. Please take a look.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com