Re: [HACKERS] Block level parallel vacuum

On Thu, Dec 5, 2019 at 12:54 AM Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>
> On Thu, Nov 21, 2019 at 12:32 AM Dilip Kumar <dilipbalaut(at)gmail(dot)com> wrote:
> > In v33-0001-Add-index-AM-field-and-callback-for-parallel-ind patch, I
> > am a bit doubtful about this kind of arrangement, where the code in
> > the "if" is always unreachable with the current AMs. I am not sure
> > what is the best way to handle this, should we just drop the
> > amestimateparallelvacuum altogether? Because currently, we are just
> > providing a size estimate function without a copy function, even if
> > the in future some Am give an estimate about the size of the stats, we
> > can not directly memcpy the stat from the local memory to the shared
> > memory, we might then need a copy function also from the AM so that it
> > can flatten the stats and store in proper format?
>
> I agree that it's a crock to add an AM method that is never used for
> anything. That's just asking for the design to prove buggy and
> inadequate. One way to avoid this would be to require that every AM
> that wants to support parallel vacuuming supply this method, and if it
> wants to just return sizeof(IndexBulkDeleteResult), then it can. But I
> also think someone should modify one of the AMs to use a
> differently-sized object, and then see whether they can really make
> parallel vacuum work with this patch. If, as you speculated here, it
> needs another API, then we should add both of them or neither. A
> half-baked solution is worse than nothing at all.
>

It is possible that we need another API to make it work as is
currently the case for Gist Index where we need to someway first
serialize it (which as mentioned earlier that we have now a way to
avoid serializing it). However, if it is for some simple case where
there are some additional constants apart from IndexBulkDeleteResult,
then we don't need it. I think here, we were cautious to not expose
more API's unless there is a real need, but I guess it is better to
completely avoid such cases and don't expose any API unless we have
some examples. In any case, the user will have the facility to
disable a parallel vacuum for such cases.

--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com