Re: Vacuum: allow usage of more than 1GB of work mem

Simon Riggs <simon@2ndquadrant.com>

From: Simon Riggs <simon@2ndquadrant.com>
To: Claudio Freire <klaussfreire@gmail.com>
Cc: Simon Riggs <simon@2ndquadrant.com>, PostgreSQL-Dev <pgsql-hackers@postgresql.org>
Date: 2016-09-05T20:36:16Z
Lists: pgsql-hackers
On 5 September 2016 at 15:50, Claudio Freire <klaussfreire@gmail.com> wrote:
> On Sun, Sep 4, 2016 at 3:46 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
>> On 3 September 2016 at 04:25, Claudio Freire <klaussfreire@gmail.com> wrote:
>>> The patch also makes vacuum free the dead_tuples before starting
>>> truncation. It didn't seem necessary to hold onto it beyond that
>>> point, and it might help give the OS more cache, especially if work
>>> mem is configured very high to avoid multiple index scans.
>>
>> How long does that part ever take? Is there any substantial gain from this?
>>
>> Lets discuss that as a potential second patch.
>
> In the test case I mentioned, it takes longer than the vacuum part itself.

Please provide a test case and timings so we can see what's happening.

-- 
Simon Riggs                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


Commits

  1. Prefetch blocks during lazy vacuum's truncation scan

  2. Explain unaccounted for space in pgstattuple.