On Wed, Jan 20, 2021 at 3:50 PM Peter Eisentraut <peter.eisentr...@enterprisedb.com> wrote: > > On 2020-10-30 02:43, Masahiko Sawada wrote: > > Using the integer set is very memory efficient (5MB vs. 114MB in the > > base case) and there is no 1GB limitation. Looking at the execution > > time, I had expected that using the integer set is slower on recording > > TIDs than using the simple array but in this experiment, there is no > > big difference among methods. Perhaps the result will vary if vacuum > > needs to record much more dead tuple TIDs. From the results, I can see > > a good improvement in the integer set case and probably a good start > > but if we want to use it also for lazy vacuum, we will need to improve > > it so that it can be used on DSA for the parallel vacuum. > > > > I've attached the patch I used for the experiment that adds xx_vacuum > > GUC parameter that controls the method of recording TIDs. Please note > > that it doesn't support parallel vacuum. > > How do you want to proceed here? The approach of writing a wrapper for > bsearch with bound check sounded like a good start. All the other ideas > discussed here seem larger projects and would probably be out of scope > of this commit fest.
Agreed. bsearch with bound check showed a reasonable improvement in my evaluation in terms of performance. Regarding memory efficiency, we can experiment with other methods later. I've attached the patch that adds a bound check for encoded itermpointers before bsearch() in lazy_tid_reaped() and inlines the function. Regards, -- Masahiko Sawada EDB: https://www.enterprisedb.com/
bound_check_lazy_vacuum.patch
Description: Binary data
