On Thu, Dec 19, 2019 at 8:17 AM Amit Kapila <amit.kapil...@gmail.com> wrote: > > On Wed, Dec 18, 2019 at 6:02 PM Amit Kapila <amit.kapil...@gmail.com> wrote: > > > > On Wed, Dec 18, 2019 at 3:36 PM Amit Kapila <amit.kapil...@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