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

From Claudio Freire
Subject Re: [HACKERS] Block level parallel vacuum WIP
Date
Msg-id CAGTBQpaTOHfhVhQ=pCxCPM_2wTpb-EUk3vYXP4jR2QiVb2-dHA@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] Block level parallel vacuum WIP  (Masahiko Sawada <sawada.mshk@gmail.com>)
Responses Re: [HACKERS] Block level parallel vacuum WIP  (Masahiko Sawada <sawada.mshk@gmail.com>)
List pgsql-hackers
On Fri, Jan 6, 2017 at 2:38 PM, Masahiko Sawada <sawada.mshk@gmail.com> wrote:
>  table_size | indexes | parallel_degree |   time
> ------------+---------+-----------------+----------
>  6.5GB      |       0 |               1 | 00:00:14
>  6.5GB      |       0 |               2 | 00:00:02
>  6.5GB      |       0 |               4 | 00:00:02

Those numbers look highly suspect.

Are you sure you're not experiencing caching effects? (ie: maybe you
ran the second and third vacuums after the first, and didn't flush the
page cache, so the table was cached)

>  6.5GB      |       2 |               1 | 00:02:18
>  6.5GB      |       2 |               2 | 00:00:38
>  6.5GB      |       2 |               4 | 00:00:46
...
>  13GB       |       0 |               1 | 00:03:52
>  13GB       |       0 |               2 | 00:00:49
>  13GB       |       0 |               4 | 00:00:50
..
>  13GB       |       2 |               1 | 00:12:42
>  13GB       |       2 |               2 | 00:01:17
>  13GB       |       2 |               4 | 00:02:12

These would also be consistent with caching effects



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [HACKERS] ALTER TABLE .. ALTER COLUMN .. ERROR: attribute .. has wrong type
Next
From: Peter Geoghegan
Date:
Subject: [HACKERS] Subtle bug in "Simplify tape block format" commit