Re: Parallel heap vacuum

On Mon, Mar 10, 2025 at 11:57 PM Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote:
>
> On Sun, Mar 9, 2025 at 11:12 PM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> >
> >
> > > However, in the heap vacuum phase, the leader process needed
> > > to process all blocks, resulting in soft page faults while creating
> > > Page Table Entries (PTEs). Without the patch, the backend process had
> > > already created PTEs during the heap scan, thus preventing these
> > > faults from occurring during the heap vacuum phase.
> > >
> >
> > This part is again not clear to me because I am assuming all the data
> > exists in shared buffers before the vacuum, so why the page faults
> > will occur in the first place.
>
> IIUC PTEs are process-local data. So even if physical pages are loaded
> to PostgreSQL's shared buffer (and paga caches), soft page faults (or
> minor page faults)[1] can occur if these pages are not yet mapped in
> its page table.
>

Okay, I got your point. BTW, I noticed that even for the case where
all the data is in shared_buffers, the performance improvement for
workers greater than two does decrease marginally. Am I reading the
data correctly? If so, what is the theory, and do we have
recommendations for a parallel degree?

--
With Regards,
Amit Kapila.