On Sat, Feb 9, 2019 at 11:47 PM Masahiko Sawada <sawada.m...@gmail.com> wrote:
> 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? > The scenario where the stats should pass NULL to btvacuumcleanup function is when there no dead tuples, I just think that we may use that deadtuples structure to find out whether stats should pass NULL or not while avoiding the extra memcpy. > > 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. > Yes, understood. If possible removing the need of memcpy would be good. The latest patch doesn't apply anymore. Needs a rebase. Regards, Haribabu Kommi Fujitsu Australia
