On Sun, Sep 4, 2016 at 3:46 AM, Simon Riggs <si...@2ndquadrant.com> wrote: > On 3 September 2016 at 04:25, Claudio Freire <klaussfre...@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. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers