> 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.
In Simon's original email, he suggested forcing an automatic ANALYZE on the server side after CREATE TABLE AS. I objected on the grounds that this won't fix anything for people who are doing bulk data loads using any other mechanism. Here, you're proposing the exact same thing, except instead of restricting it to people who use CREATE TABLE AS, you're restricting it to people who use a hypothetical parallelized implementation of pg_restore. While either of these is better than doing nothing, ISTM it would be far better to give the database some smarts about what constitutes a bulk data load (a whole bunch of insert operations on a newly created table) and what to do about it (synchronous analyze just before the first operation on the table that isn't an insert - and perhaps not before). ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
