| From: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
|---|---|
| To: | Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> |
| Cc: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Pavan Deolasee <pavan(dot)deolasee(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Block level parallel vacuum WIP |
| Date: | 2017-01-09 09:01:40 |
| Message-ID: | CANP8+jKWOw6AAorFOjdynxUKqs6XRReOcNy-VXRFFU_4bBT8ww@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 9 January 2017 at 08:48, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote:
> I had not considered necessity of dead lock detection support.
It seems like a big potential win to scan multiple indexes in parallel.
What do we actually gain from having the other parts of VACUUM execute
in parallel? Does truncation happen faster in parallel? ISTM we might
reduce the complexity of this if there is no substantial gain.
Can you give us some timings for performance of the different phases,
with varying levels of parallelism?
Does the design for collecting dead TIDs use a variable amount of
memory? Does this work negate the other work to allow VACUUM to use >
1GB memory?
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Pavel Stehule | 2017-01-09 09:05:49 | Re: merging some features from plpgsql2 project |
| Previous Message | Pavel Stehule | 2017-01-09 09:01:15 | Re: merging some features from plpgsql2 project |