Re: Boundary value check in lazy_tid_reaped() - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: Boundary value check in lazy_tid_reaped()
Date
Msg-id 70e1c1e9-b4b4-346f-e9fc-18d006bab444@enterprisedb.com
Whole thread Raw
In response to Re: Boundary value check in lazy_tid_reaped()  (Masahiko Sawada <masahiko.sawada@2ndquadrant.com>)
Responses Re: Boundary value check in lazy_tid_reaped()  (Masahiko Sawada <sawada.mshk@gmail.com>)
List pgsql-hackers
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.



pgsql-hackers by date:

Previous
From: Tatsuro Yamada
Date:
Subject: Re: list of extended statistics on psql
Next
From: Peter Eisentraut
Date:
Subject: Re: a misbehavior of partition row movement (?)