On 27 September 2014 03:55, Jeff Janes <jeff.janes@gmail.com> wrote:
> On Fri, Sep 26, 2014 at 11:47 AM, Alvaro Herrera <alvherre@2ndquadrant.com>
> wrote:
>>
>> Gavin Flower wrote:
>>
>> > Curious: would it be both feasible and useful to have multiple
>> > workers process a 'large' table, without complicating things too
>> > much? The could each start at a different position in the file.
>>
>> Feasible: no. Useful: maybe, we don't really know. (You could just as
>> well have a worker at double the speed, i.e. double vacuum_cost_limit).
>
>
> Vacuum_cost_delay is already 0 by default. So unless you changed that,
> vacuum_cost_limit does not take effect under vacuumdb.
>
> It is pretty easy for vacuum to be CPU limited, and even easier for analyze
> to be CPU limited (It does a lot of sorting). I think analyzing is the main
> use case for this patch, to shorten the pg_upgrade window. At least, that
> is how I anticipate using it.
I've been trying to review this thread with the thought "what does
this give me?". I am keen to encourage contributions and also keen to
extend our feature set, but I do not wish to complicate our code base.
Dilip's developments do seem to be good quality; what I question is
whether we want this feature.
This patch seems to allow me to run multiple VACUUMs at once. But I
can already do this, with autovacuum.
Is there anything this patch can do that cannot be already done with autovacuum?
-- Simon Riggs http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services