Re: Block level parallel vacuum WIP - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Block level parallel vacuum WIP
Date
Msg-id CAB7nPqRgS1FX6mREYGxx5bbQUz0co3Z7ory-KJYrko7RqkpFBg@mail.gmail.com
Whole thread Raw
In response to Re: Block level parallel vacuum WIP  (Amit Kapila <amit.kapila16@gmail.com>)
Responses Re: Block level parallel vacuum WIP  (Pavan Deolasee <pavan.deolasee@gmail.com>)
List pgsql-hackers
On Tue, Aug 23, 2016 at 10:50 PM, Amit Kapila <amit.kapila16@gmail.com> wrote:
> On Tue, Aug 23, 2016 at 6:11 PM, Michael Paquier
> <michael.paquier@gmail.com> wrote:
>> On Tue, Aug 23, 2016 at 8:02 PM, Masahiko Sawada <sawada.mshk@gmail.com> wrote:
>>> As for PoC, I implemented parallel vacuum so that each worker
>>> processes both 1 and 2 phases for particular block range.
>>> Suppose we vacuum 1000 blocks table with 4 workers, each worker
>>> processes 250 consecutive blocks in phase 1 and then reclaims dead
>>> tuples from heap and indexes (phase 2).
>>
>> So each worker is assigned a range of blocks, and processes them in
>> parallel? This does not sound performance-wise. I recall Robert and
>> Amit emails on the matter for sequential scan that this would suck
>> performance out particularly for rotating disks.
>>
>
> The implementation in patch is same as we have initially thought for
> sequential scan, but turned out that it is not good way to do because
> it can lead to inappropriate balance of work among workers.  Suppose
> one worker is able to finish it's work, it won't be able to do more.

Ah, so it was the reason. Thanks for confirming my doubts on what is proposed.
-- 
Michael



pgsql-hackers by date:

Previous
From: Jim Nasby
Date:
Subject: Re: pg_dump with tables created in schemas created by extensions
Next
From: Tomas Vondra
Date:
Subject: Re: [Patch] Temporary tables that do not bloat pg_catalog (a.k.a fast temp tables)