On Tue, Oct 4, 2016 at 7:50 PM, Robert Haas <robertmh...@gmail.com> wrote: > On Mon, Oct 3, 2016 at 5:44 PM, Alvaro Herrera <alvhe...@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. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
