On Thu, Dec 19, 2019 at 8:17 AM Amit Kapila <amit.kapila16@gmail.com> wrote:
>
> On Wed, Dec 18, 2019 at 6:02 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
> >
> > On Wed, Dec 18, 2019 at 3:36 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
> > >
> > > Few other comments which I have not fixed:
> > >
> >
> > + /* interface function to support parallel vacuum */
> > + amestimateparallelvacuum_function amestimateparallelvacuum; /*
> > can be NULL */
> > } IndexAmRoutine;
> >
> > One more thing, why have you removed the estimate function for API
> > patch?
> >
>
> Again thinking about this, it seems to me what you have done here is
> probably the right direction because whatever else we will do we need
> to have some untested code or we need to write/enhance some IndexAM to
> test this. The point is that we don't have any IndexAM in the core
> (after working around Gist index) which has this requirement and we
> have not even heard from anyone of such usage, so there is a good
> chance that whatever we do might not be sufficient for the IndexAM
> that have such usage.
>
> Now, we are already providing an option that one can set
> VACUUM_OPTION_NO_PARALLEL to indicate that the IndexAM can't
> participate in a parallel vacuum. So, I feel if there is any IndexAM
> which would like to pass more data along with IndexBulkDeleteResult,
> they can use that option. It won't be very difficult to enhance or
> provide the new APIs to support a parallel vacuum if we come across
> such a usage. I think we should just modify the comments atop
> VACUUM_OPTION_NO_PARALLEL to mention this. I think this should be
> good enough for the first version of parallel vacuum considering we
> are able to support a parallel vacuum for all in-core indexes.
>
> Thoughts?
+1
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
