On Thu, Oct 17, 2019 at 6:13 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
>
> On Wed, Oct 16, 2019 at 5:35 PM Masahiko Sawada <sawada.mshk@gmail.com> wrote:
> >
> > On Wed, Oct 16, 2019 at 3:48 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
> > >
> > >
> > > It is not that currently, other indexes don't use any additional
> > > memory (except for maintainence_work_mem). For example, Gist index
> > > can use memory for collecting empty leaf pages and internal pages. I
> > > am not sure if we can do anything for such cases. The case for Gin
> > > index seems to be clear and it seems to be having the risk of using
> > > much more memory, so why not try to do something for it?
> >
> > Yeah gin indexes is clear now and I agree that we need to do something
> > for it. But I'm also concerned third party index AMs. Similar to the
> > problem related to IndexBulkDeleteResult structure that we're
> > discussing on another thread I thought that we have the same problem
> > on this.
> >
>
> I understand your concern, but I am not sure what is a good way to
> deal with it. I think we can do something generic like divide the
> maintainence_work_mem equally among workers, but then the indexes that
> use maintainence_work_mem will suffer if the number of such indexes is
> much less than the indexes that don't use maintainence_work_mem.
> Another idea could be each index AM tell whether it uses
> maintainence_work_mem or not and based on that we can do the
> computation (divide the maintainence_work_mem by the number of such
> indexes during parallel vacuum). Do you have any other ideas for
> this?
>
I was thinking the similar idea to the latter idea: ask index AM the
amount of memory (that should be part of maintenance_work_mem) it will
consume and then compute the new limit for both heap scan and index
vacuuming based on that.
Regards,
--
Masahiko Sawada