Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> writes:
> Alvaro Herrera wrote:
>> Why doesn't this new request conflict with that one?
> The problem back then was that a CREATE INDEX was waiting on the
> autoanalyze to finish, and the autoanalyze took a long time to finish
> because of vacuum_cost_delay. Now that we have the auto-cancel
> mechanism, that's not a problem.
Define "not a problem". With auto-cancel, what will happen is that
whatever work the autoanalyze does will be wasted. It seems to me
that the current complaint is about background autovacuum/autoanalyze
wasting cycles during a bulk load, and there's certainly no purer waste
than an analyze cycle that gets aborted.
I tend to agree with Alvaro that there's not very much of a use case for
an analyze-only autovacuum mode. Assuming that we get to the point of
having a parallelizing pg_restore, it would be interesting to give it an
option to include ANALYZE for each table it's loaded among the tasks
that it schedules. (I'm visualizing these commands as being made up by
pg_restore itself, *not* added to the pg_dump output.) Then you could
have a reasonably optimal total workflow, whereas allowing autovacuum
to try to schedule the ANALYZEs can't be.
regards, tom lane
