Re: Parallel heap vacuum
От | Melanie Plageman |
---|---|
Тема | Re: Parallel heap vacuum |
Дата | |
Msg-id | CAAKRu_YA4AqoVgOCDN9MyDRgODsEZV7ZFax6UGiyTySWrr+X6w@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Parallel heap vacuum (Masahiko Sawada <sawada.mshk@gmail.com>) |
Ответы |
Re: Parallel heap vacuum
|
Список | pgsql-hackers |
On Mon, Feb 17, 2025 at 1:11 PM Masahiko Sawada <sawada.mshk@gmail.com> wrote: > > On Fri, Feb 14, 2025 at 2:21 PM Melanie Plageman > <melanieplageman@gmail.com> wrote: > > > > Since the failure rate is defined as a percent, couldn't we just have > > parallel workers set eager_scan_remaining_fails when they get their > > chunk assignment (as a percentage of their chunk size)? (I haven't > > looked at the code, so maybe this doesn't make sense). > > IIUC since the chunk size eventually becomes 1, we cannot simply just > have parallel workers set the failure rate to its assigned chunk. Yep. The ranges are too big (1-8192). The behavior would be too different from serial. > > Also, if you start with only doing parallelism for the third phase of > > heap vacuuming (second pass over the heap), this wouldn't be a problem > > because eager scanning only impacts the first phase. > > Right. I'm inclined to support only the second heap pass as the first > step. If we support parallelism only for the second pass, it cannot > help speed up freezing the entire table in emergency situations, but > it would be beneficial for cases where a big table have a large amount > of spread garbage. > > At least, I'm going to reorganize the patch set to support parallelism > for the second pass first and then the first heap pass. Makes sense. - Melanie
В списке pgsql-hackers по дате отправления: