On Tue, Feb 5, 2019 at 12:14 PM Haribabu Kommi <kommi.harib...@gmail.com> wrote: > > > On Fri, Feb 1, 2019 at 8:19 AM Masahiko Sawada <sawada.m...@gmail.com> wrote: >> >> >> The passing stats = NULL to amvacuumcleanup and ambulkdelete means the >> first time execution. For example, btvacuumcleanup skips cleanup if >> it's not NULL.In the normal vacuum we pass NULL to ambulkdelete or >> amvacuumcleanup when the first time calling. And they store the result >> stats to the memory allocated int the local memory. Therefore in the >> parallel vacuum I think that both worker and leader need to move it to >> the shared memory and mark it as updated as different worker could >> vacuum different indexes at the next time. > > > OK, understood the point. But for btbulkdelete whenever the stats are NULL, > it allocates the memory. So I don't see a problem with it. > > The only problem is with btvacuumcleanup, when there are no dead tuples > present in the table, the btbulkdelete is not called and directly the > btvacuumcleanup > is called at the end of vacuum, in that scenario, there is code flow > difference > based on the stats. so why can't we use the deadtuples number to differentiate > instead of adding another flag?
I don't understand your suggestion. What do we compare deadtuples number to? Could you elaborate on that please? > And also this scenario is not very often, so avoiding > memcpy for normal operations would be better. It may be a small gain, just > thought of it. > This scenario could happen periodically on an insert-only table. Additional memcpy is executed once per indexes in a vacuuming but I agree that the avoiding memcpy would be good. Regards, -- Masahiko Sawada NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center
