Simon Riggs <si...@2ndquadrant.com> writes:
> On Sat, Apr 30, 2011 at 11:48 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
>> A bigger objection to this patch is that it seems quite incomplete.
>> I'm not sure there's much point in adding delays to the first loop of
>> copy_heap_data() without also providing for delays inside the sorting
>> code and the eventual index rebuilds; which will make the patch
>> significantly more complicated and invasive.
> The patch puts the old behaviour of vacuum delay back into VACUUM FULL
> and seems worth backpatching to 9.0 and 9.1 to me, since it is so
> simple.
No, it does perhaps 1% of what's needed to make the new implementation
react to vacuum_cost_delay in a useful way. I see no point in applying
this as-is, let alone back-patching it.
> Previously there wasn't any delay in the sort or indexing either, so
> it's a big ask to put that in now and it would also make backpatching
> harder.
You're missing the point: there wasn't any sort or reindex in the old
implementation of VACUUM FULL. The CLUSTER-based implementation makes
use of very large chunks of code that were simply never used before
by VACUUM.
>> Another question is whether this is the right place to be looking
>> at all. If Gabriele's setup can't keep up with replication when a
>> VAC FULL is running, then it can't keep up when under load, period.
>> This seems like a pretty band-aid-ish response to that sort of problem.
> This isn't about whether the system can cope with the load, its about
> whether replication lag is affected by the load.
And I think you're missing the point here too. Even if we cluttered
the system to the extent of making all steps of VACUUM FULL honor
vacuum_cost_delay, it wouldn't fix Gabriele's problem, because any other
I/O-intensive query would produce the same effect. We could further
clutter everything else that someone defines as a "maintenance query",
and it *still* wouldn't fix the problem. It would be much more
profitable to attack the performance of replication directly. I don't
really feel a need to put cost_delay stuff into anything that's not used
by autovacuum.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
