> I don't think any of these progress callbacks should be done while pinning > a > buffer and ...
Good point. > I also don't understand why info->parallel_progress_callback exists? It's > only > set to parallel_vacuum_progress_report(). Why make this stuff more > expensive > than it has to already be? Agree. Modified the patch to avoid the callback . > So each of the places that call this need to make an additional external > function call for each page, just to find that there's nothing to do or to > make yet another indirect function call. This should probably a static > inline > function. Even better to just remove a function call altogether. > This is called, for every single page, just to read the number of indexes > completed by workers? A number that barely ever changes? I will take the initial suggestion by Sawada-san to update the progress every 1GB of blocks scanned. Also, It sems to me that we don't need to track progress in brin indexes, Since it is rare, if ever, this type of index will go through very heavy block scans. In fact, I noticed the vacuum AMs for brin don't invoke the vacuum_delay_point at all. The attached patch addresses the feedback. Regards, Sami Imseih Amazon Web Services (AWS)
v15-0001-Add-2-new-columns-to-pg_stat_progress_vacuum.-Th.patch
Description: v15-0001-Add-2-new-columns-to-pg_stat_progress_vacuum.-Th.patch
