| From: | Melanie Plageman <melanieplageman(at)gmail(dot)com> |
|---|---|
| To: | Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> |
| Cc: | Andres Freund <andres(at)anarazel(dot)de>, Peter Smith <smithpb2250(at)gmail(dot)com>, John Naylor <johncnaylorls(at)gmail(dot)com>, Tomas Vondra <tomas(at)vondra(dot)me>, "Hayato Kuroda (Fujitsu)" <kuroda(dot)hayato(at)fujitsu(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Parallel heap vacuum |
| Date: | 2025-04-06 18:51:10 |
| Message-ID: | CAAKRu_ajnk7J4LjOXqh2V1=FZpTMkTpKZACpZ4tCt7UR3o9tqw@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Sun, Apr 6, 2025 at 1:02 AM Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote:
>
> The eager freeze scan is the pre-existing feature but it's pretty new
> code that was pushed just a couple months ago. I didn't want to make
> the newly introduced code complex further in one major release
> especially if it's in a vacuum area. While I agree that disabling
> eager freeze scans during parallel heap vacuum is not very
> user-friendly, there are still many cases where parallel heap vacuum
> helps even without the eager freeze scan. FYI the parallel heap scan
> can be disabled by setting min_parallel_table_scan_size. So I thought
> we can incrementally improve this part.
min_parallel_table_scan_size also affects parallel sequential scans,
though. And AFAIK, that can only be configured globally (i.e. not for
a specific table).
I wonder if there is a clear way to make specific phases of vacuum
using parallelism configurable.
- Melanie
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Melanie Plageman | 2025-04-06 19:19:34 | Re: New criteria for autovacuum |
| Previous Message | Chapman Flack | 2025-04-06 18:16:38 | Re: FmgrInfo allocation patterns (and PL handling as staged programming) |