From: | Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> |
---|---|
To: | Юрий Соколов <funny(dot)falcon(at)gmail(dot)com> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: [HACKERS] Block level parallel vacuum |
Date: | 2018-11-02 09:26:02 |
Message-ID: | CAD21AoB6+_BrADgGw=oPvp0qNT2A=C=zLasXb8p3S49tCYwQTA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On Thu, Nov 1, 2018 at 2:28 PM Yura Sokolov <funny(dot)falcon(at)gmail(dot)com> wrote:
>
> Excuse me for being noisy.
>
> Increasing vacuum's ring buffer improves vacuum upto 6 times.
> https://www.postgresql.org/message-id/flat/20170720190405.GM1769%40tamriel.snowman.net
> This is one-line change.
>
> How much improvement parallel vacuum gives?
It depends on hardware resources you can use.
In current design the scanning heap and vacuuming heap are procesed
with parallel workers at block level (using parallel sequential scan)
and the vacuuming indexes are also processed with parallel worker at
index-level. So even if a table is not large enough the more a table
has indexes you can get better performance. The performance test
result (I attached) I did before shows that parallel vacuum is up to
almost 10 times faster than single-process vacuum in a case. The test
used not-large table (4GB table) with many indexes but it would be
insteresting to test with large table.
Regards,
--
Masahiko Sawada
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
Attachment | Content-Type | Size |
---|---|---|
parallel_vacuum.png | image/png | 85.2 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Evgeniy Efimkin | 2018-11-02 09:34:31 | Special role for subscriptions |
Previous Message | Sergei Kornilov | 2018-11-02 09:25:10 | pg_ls_dir_files issue with concurrent file unlink |