From: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
---|---|
To: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
Cc: | Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Block level parallel vacuum WIP |
Date: | 2016-08-23 13:50:36 |
Message-ID: | CAA4eK1K9aN6Msnx-UDy7EfoiBS4MfGxaQPcc=U-zxSMhoKYNtQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Aug 23, 2016 at 6:11 PM, Michael Paquier
<michael(dot)paquier(at)gmail(dot)com> wrote:
> On Tue, Aug 23, 2016 at 8:02 PM, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)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.
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2016-08-23 13:50:55 | Re: Block level parallel vacuum WIP |
Previous Message | Amit Kapila | 2016-08-23 13:35:51 | Re: Proposal for CSN based snapshots |