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 mean, to me someone who does this must have a very
big db on a big iron. If that does not consist of thousands and
thousands of smallish relations, it will normally be some very big
tables and a much smaller catalog. Then you can vacuum paralell
everything but system catalogs and then vaccum serial those. I do not
have that big dbs, but in my modest case system catalogs are very fast
to vacuum. If 99% of the time is spent vacuuming non-system it does
not make much sense to spend effort on speeding maybe one half of the
system catalogs vacuum ( I mean, 99% of the time is non-system, half
of system can be done in paralell, with a ten-fold speed up we go from
99+0.5+0.5 to 9.9+0.5+0.5 = 10.9 with full serial system catalogs and
to 9.9+0.5+0.05=10.45 with hybrid system vacuum and with a 100 fold
speedup, in the realm of SF for me, to 0.99+0.5+0.5=1.99 and
0.99+0.5+0.05=1.54, not that much to be gained )
( Just asking. )
OTOH while I dig into the code I will take a look to see how complex
it will be to build to lists, paralell + serial, and loop on them.
This could be used on a first approach to split on !pg_catalog +
pg_catalog and used as a base for having and explicit list or some
flag in the catalog later.
Francisco Olarte.
