Thread: Parallel VACUUM in feature matrix on website
It's not really parallel VACUUM, is it? So why call it parallel VACUUM? -- Regards, Peter Geoghegan
Also, I think "WAL Buffer auto-tuning" should be cut. It doesn't warrant inclusion here. There are one or two other items that should be pruned too, but less obviously so. -- Regards, Peter Geoghegan
On 27 September 2015 at 20:33, Peter Geoghegan <peter.geoghegan86@gmail.com> wrote: > It's not really parallel VACUUM, is it? So why call it parallel VACUUM? It allows multiple vacuum processes to be initiated from vacuumdb at the same time (i.e. in parallel), although not for the same tables. What do you propose would be more appropriate? Thom
On Sun, Sep 27, 2015 at 12:39 PM, Thom Brown <thom@linux.com> wrote: > It allows multiple vacuum processes to be initiated from vacuumdb at > the same time (i.e. in parallel), although not for the same tables. > What do you propose would be more appropriate? "Parallel vacuumdb jobs" seems better. I have seen cases where the existing wording caused confusion. I think that we will probably have actual parallel vacuum within the next couple of releases (probably vacuuming multiple indexes at the same time, using a list of TIDs in shared memory). The messaging here is important. -- Regards, Peter Geoghegan
2015-09-27 21:39 GMT+02:00 Thom Brown <thom@linux.com>:
On 27 September 2015 at 20:33, Peter Geoghegan
<peter.geoghegan86@gmail.com> wrote:
> It's not really parallel VACUUM, is it? So why call it parallel VACUUM?
It allows multiple vacuum processes to be initiated from vacuumdb at
the same time (i.e. in parallel), although not for the same tables.
What do you propose would be more appropriate?
Sounds more like a parallel vacuumdb, than a parallel VACUUM, to me :)
--
On 27 September 2015 at 20:43, Peter Geoghegan <peter.geoghegan86@gmail.com> wrote: > On Sun, Sep 27, 2015 at 12:39 PM, Thom Brown <thom@linux.com> wrote: >> It allows multiple vacuum processes to be initiated from vacuumdb at >> the same time (i.e. in parallel), although not for the same tables. >> What do you propose would be more appropriate? > > "Parallel vacuumdb jobs" seems better. I have seen cases where the > existing wording caused confusion. > > I think that we will probably have actual parallel vacuum within the > next couple of releases (probably vacuuming multiple indexes at the > same time, using a list of TIDs in shared memory). The messaging here > is important. Okay, I've changed it to "Parallel vacuumdb jobs". Thom
On Sun, Sep 27, 2015 at 1:06 PM, Thom Brown <thom@linux.com> wrote: > Okay, I've changed it to "Parallel vacuumdb jobs". Thanks. -- Regards, Peter Geoghegan
On 09/27/2015 12:39 PM, Peter Geoghegan wrote: > Also, I think "WAL Buffer auto-tuning" should be cut. It doesn't > warrant inclusion here. There are one or two other items that should > be pruned too, but less obviously so. > I disagree here; I think that anything which eliminates a need for manual tuning is a significant feature. Expecially if you're looking at the chart and trying to remember "hey, do I need to tune checkpoint segments on this version?" -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com
On 2015-09-28 10:22 AM, Josh Berkus wrote: > On 09/27/2015 12:39 PM, Peter Geoghegan wrote: >> Also, I think "WAL Buffer auto-tuning" should be cut. It doesn't >> warrant inclusion here. There are one or two other items that should >> be pruned too, but less obviously so. > > I disagree here; I think that anything which eliminates a need for > manual tuning is a significant feature. Expecially if you're looking at > the chart and trying to remember "hey, do I need to tune checkpoint > segments on this version?" I totally agree with Josh. Especially for newer or less-savvy users, this means it just became easier to use Postgres in a performant way, and ease of use gets customers. -- Darren Duncan