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

From: Claudio Freire <klaussfreire(at)gmail(dot)com>
To: Simon Riggs <simon(at)2ndquadrant(dot)com>
Cc: PostgreSQL-Dev <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Vacuum: allow usage of more than 1GB of work mem
Date: 2016-09-05 19:15:40
Views: Raw Message | Whole Thread | Download mbox
Lists: pgsql-hackers

On Mon, Sep 5, 2016 at 11:50 AM, Claudio Freire <klaussfreire(at)gmail(dot)com> wrote:
> On Sun, Sep 4, 2016 at 3:46 AM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
>> On 3 September 2016 at 04:25, Claudio Freire <klaussfreire(at)gmail(dot)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.
> Other than freeing RAM there's no gain. I didn't measure any speed
> difference while testing, but that's probably because the backward
> scan doesn't benefit from the cache, but other activity on the system
> might. So, depending on the workload on the server, extra available
> RAM may be a significant gain on its own or not. It just didn't seem
> there was a reason to keep that RAM reserved, especially after making
> it a huge allocation.
> I'm fine either way. I can remove that from the patch or leave it
> as-is. It just seemed like a good idea at the time.

Rebased and split versions attached

Attachment Content-Type Size
0001-Vacuum-allow-using-more-than-1GB-work-mem.patch text/x-patch 1.5 KB
0002-Vacuum-free-dead_tuples-sooner.patch text/x-patch 1.8 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Steve Singer 2016-09-05 19:58:11 Re: Logical Replication WIP
Previous Message Mithun Cy 2016-09-05 18:50:23 Re: Cache Hash Index meta page.