Peter Eisentraut <pete...@gmx.net> writes:
> initdb currently does
> PG_CMD_PUTS("ANALYZE;\nVACUUM FULL;\nVACUUM FREEZE;\n");
> FREEZE is now part of FULL, so this seems redundant. Also, ANALYZE can
> be run as part of VACUUM. So this could be
> PG_CMD_PUTS("VACUUM FULL ANALYZE;\n");
Merging the ANALYZE step would save few cycles, and it'd probably result
in the contents of pg_statistic being at least partly unfrozen at the end
of the process, so please don't go that far.
> There has been some concerns about time spent in initdb in test suites,
> which is why I looked into this. In testing, this change can shave off
> between 10% and 20% of the run time of initdb, so it would be kind of
> useful.
> The last change to this was
> commit 66cd8150636e48a8f143560136a25ec5eb355d8c
> Author: Tom Lane <t...@sss.pgh.pa.us>
> Date: Mon Nov 29 03:05:03 2004 +0000
> Clean up initdb's error handling so that it prints something more
> useful than just \'failed\' when there's a problem. Per gripe from
> Chris Albertson.
> In an unrelated change, use VACUUM FULL; VACUUM FREEZE; rather than
> a single VACUUM FULL FREEZE command, to respond to my worries of a
> couple days ago about the reliability of doing this in one go.
> That was a long time ago. Is that still applicable?
Probably not; what I was on about was
http://www.postgresql.org/message-id/12179.1101591...@sss.pgh.pa.us
which certainly isn't a case that exists anymore since we got rid
of the old VACUUM FULL implementation. So I think we could go to
PG_CMD_PUTS("ANALYZE;\nVACUUM FULL FREEZE;\n");
without any degradation of the intended results.
Another idea would be to drop the FULL part and make this
PG_CMD_PUTS("ANALYZE;\nVACUUM FREEZE;\n");
which would speed initdb but it would also lose the testing angle
of being sure that we can VACUUM FULL all system catalogs. OTOH,
I don't immediately see why we shouldn't test that somewhere in the
regression tests rather than in every initdb. (I think part of the
argument for the forced FULL was to make sure we broke anything that
thought system catalogs had fixed relfilenodes, but that should be
pretty well a done deal by now.)
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
