Re: Vacuum: allow usage of more than 1GB of work mem
Claudio Freire <klaussfreire@gmail.com>
From: Claudio Freire <klaussfreire@gmail.com>
To: Simon Riggs <simon@2ndquadrant.com>
Cc: PostgreSQL-Dev <pgsql-hackers@postgresql.org>
Date: 2016-09-05T19:15:40Z
Lists: pgsql-hackers
Attachments
- 0001-Vacuum-allow-using-more-than-1GB-work-mem.patch (text/x-patch) patch 0001
- 0002-Vacuum-free-dead_tuples-sooner.patch (text/x-patch) patch 0002
On Mon, Sep 5, 2016 at 11:50 AM, 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. > > 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
Commits
-
Prefetch blocks during lazy vacuum's truncation scan
- 7e26e02eec90 10.0 landed
-
Explain unaccounted for space in pgstattuple.
- 71f996d22125 10.0 cited