Re: [HACKERS] Block level parallel vacuum

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.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company