Re: Vacuum: allow usage of more than 1GB of work mem
Simon Riggs <simon@2ndquadrant.com>
From: Simon Riggs <simon@2ndquadrant.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Simon Riggs <simon@2ndquadrant.com>, Robert Haas <robertmhaas@gmail.com>, Claudio Freire <klaussfreire@gmail.com>,
Jim Nasby <Jim.Nasby@bluetreble.com>, PostgreSQL-Dev <pgsql-hackers@postgresql.org>
Date: 2016-09-07T12:45:50Z
Lists: pgsql-hackers
Attachments
- vacuum_mem_estimate.v1.patch (application/octet-stream) patch v1
On 6 September 2016 at 19:59, Tom Lane <tgl@sss.pgh.pa.us> wrote: > The idea of looking to the stats to *guess* about how many tuples are > removable doesn't seem bad at all. But imagining that that's going to be > exact is folly of the first magnitude. Yes. Bear in mind I had already referred to allowing +10% to be safe, so I think we agree that a reasonably accurate, yet imprecise calculation is possible in most cases. If a recent transaction has committed, we will see both committed dead rows and stats to show they exist. I'm sure there are corner cases and race conditions where a major effect (greater than 10%) could occur, in which case we run the index scan more than once, just as we do now. The attached patch raises the limits as suggested by Claudio, allowing for larger memory allocations if possible, yet limits the allocation for larger tables based on the estimate gained from pg_stats, while adding 10% for caution. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Commits
-
Prefetch blocks during lazy vacuum's truncation scan
- 7e26e02eec90 10.0 landed
-
Explain unaccounted for space in pgstattuple.
- 71f996d22125 10.0 cited