On Tue, Oct 22, 2019 at 10:53 AM Amit Kapila <amit.kapil...@gmail.com> wrote:
>
> On Tue, Oct 22, 2019 at 10:50 AM Dilip Kumar <dilipbal...@gmail.com> wrote:
> >
> > On Tue, Oct 22, 2019 at 9:10 AM Amit Kapila <amit.kapil...@gmail.com> wrote:
> > >
> > > On Fri, Oct 18, 2019 at 4:51 PM Dilip Kumar <dilipbal...@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

Attachment: v2-0001-delete-empty-page-in-gistbulkdelete.patch
Description: Binary data

Reply via email to