Robert Haas wrote:
> On Wed, Oct 5, 2016 at 10:58 AM, Francisco Olarte
> <folarte@peoplecall.com> wrote:
> > On Tue, Oct 4, 2016 at 7:50 PM, Robert Haas <robertmhaas@gmail.com> wrote:
> >> On Mon, Oct 3, 2016 at 5:44 PM, Alvaro Herrera <alvherre@2ndquadrant.com> wrote:
> > ...
> >>> I wonder if the real answer isn't just to disallow -f with parallel
> >>> vacuuming.
> >> Seems like we should figure out which catalog tables are needed in
> >> order to perform a VACUUM, and force those to be done last and one at
> >> a time.
> >
> > Is the system catalog a bottleneck for people who has real use for
> > paralell vacuum?
>
> I don't know, but it seems like the documentation for vacuumdb
> currently says, more or less, "Hey, if you use -j with -f, it may not
> work!", which seems unacceptable to me. It should be the job of the
> person writing the feature to make it work in all cases, not the job
> of the person using the feature to work around the problem when it
> doesn't.
The most interesting use case of vacuumdb is lazy vacuuming, I think, so
committing that patch as it was submitted previously was a good step
forward even if it didn't handle VACUUM FULL 100%.
I agree that it's better to have both modes Just Work in parallel, which
is the point of this subsequent patch. So let's move forward. I
support Francisco's effort to make -f work with -j. I don't have a
strong opinion on which of the various proposals presented so far is the
best way to implement it, but let's figure that out and get it done.
If you want to argue that vacuumdb -f -j not working properly is a bug
in the vacuumdb -j commit, ISTM you're arguing that we should backpatch
whatever we come up with as a bug fix, but I would disagree with that.
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services