On Mon, Feb 24, 2025 at 8:15 PM Masahiko Sawada <sawada.m...@gmail.com> wrote: > > What I can see from these results was that we might not benefit much > from parallelizing phase III, unfortunately. Although in the best case > the phase III got about 2x speedup, as for the total duration it's > about only 10% speedup. My analysis for these results matches what > John mentioned; phase III is already the fastest phase and accounts > only ~10% of the total execution time, and the overhead of shared > TidStore offsets the speedup of phase III.
So, are you proposing to drop the patches for parallelizing phase III for now? If so, are you planning on posting a set of patches just to parallelize phase I? I haven't looked at the prelim refactoring patches to see if they have independent value. What do you think is reasonable for us to try and do in the next few weeks? > > The same commit that made the parallel scanning patch more difficult > > should also reduce the risk of having a large amount of freezing work > > at once in the first place. (There are still plenty of systemic things > > that can go wrong, of course, and it's always good if unpleasant work > > finishes faster.) > > I think that vacuum would still need to scan a large amount of blocks > of the table especially when it is very large and heavily modified. > Parallel heap vacuum (only phase I) would be beneficial in case where > autovacuum could not catch up. And we might want to consider using > parallel heap vacuum also in autovacuum while integrating it with > eagar freeze scan. I'd be interested to hear more about this. - Melanie
