On Mon, Feb 24, 2025 at 8:15 PM Masahiko Sawada <sawada.mshk@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
