Horton

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

Jim Nasby <jim.nasby@bluetreble.com>

View thread View on postgr.es
From: Jim Nasby <Jim.Nasby@BlueTreble.com>
To: Simon Riggs <simon@2ndquadrant.com>, Claudio Freire <klaussfreire@gmail.com>
Cc: PostgreSQL-Dev <pgsql-hackers@postgresql.org>
Date: 2016-09-04T23:10:36Z
Lists: pgsql-hackers 
On 9/4/16 1:46 AM, Simon Riggs 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?

If you're asking about how long the dealloc takes, we're going to have 
to pay that cost anyway when the context gets destroyed/reset, no? Doing 
that sooner rather than later certainly seems like a good idea since 
we've seen that truncation can take quite some time. Might as well give 
the memory back to the OS ASAP.
-- 
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com
855-TREBLE2 (855-873-2532)   mobile: 512-569-9461

Commits

  1. Prefetch blocks during lazy vacuum's truncation scan

  2. Explain unaccounted for space in pgstattuple.