Re: Parallel heap vacuum - Mailing list pgsql-hackers

From Masahiko Sawada
Subject Re: Parallel heap vacuum
Date
Msg-id CAD21AoC+pw3_YzW0uZWvWCrw38bVzqqJCv7wm8gn6BCwr--YYA@mail.gmail.com
Whole thread Raw
In response to Re: Parallel heap vacuum  (Amit Kapila <amit.kapila16@gmail.com>)
Responses Re: Parallel heap vacuum
List pgsql-hackers
On Tue, Mar 11, 2025 at 5:51 AM Amit Kapila <amit.kapila16@gmail.com> wrote:
>
> On Tue, Mar 11, 2025 at 5:00 AM Masahiko Sawada <sawada.mshk@gmail.com> wrote:
> >
> > On Sun, Mar 9, 2025 at 11:28 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
> > >
> > >
> > > Does phase 3 also use parallelism? If so, can we try to divide the
> > > ring buffers among workers or at least try vacuum with an increased
> > > number of ring buffers. This would be good to do for both the phases,
> > > if they both use parallelism.
> >
> > No, only phase 1 was parallelized in this test. In parallel vacuum,
> > since it uses (ring_buffer_size * parallel_degree) memory, more pages
> > are loaded during phase 1, increasing cache hits during phase 3.
> >
>
> Shouldn't we ideally try with a vacuum without parallelism with
> ring_buffer_size * parallel_degree to make the comparison better?

Right. I'll share the benchmark test results with such configuration.

> Also, what could be the reason for the variation in data of phase-I?
> Do you restart the system after each run to ensure there is nothing in
> the memory? If not, then shouldn't we try at least a few runs by
> restarting the system before each run to ensure there is nothing
> leftover in memory?

I dropped all page caches by executing 'echo 3 >
/proc/sys/vm/drop_caches' before each run and these results are the
median of 3 runs. I'll investigate it further.

Regards,

--
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com



pgsql-hackers by date:

Previous
From: Masahiko Sawada
Date:
Subject: Re: Parallel heap vacuum
Next
From: Alena Rybakina
Date:
Subject: Re: Adding skip scan (including MDAM style range skip scan) to nbtree