Amit Kapila <amit.kapila16@gmail.com> wrote:
> Notes for Committer -
> There is one behavioural difference in the handling of --analyze-in-stages
> switch, when individual tables (by using -t option) are analyzed by
> using this switch, patch will process (in case of concurrent jobs) all the
> given tables for stage-1 and then for stage-2 and so on whereas in the
> unpatched code it will process all the three stages table by table
> (table-1 all three stages, table-2 all three stages and so on). I think
> the new behaviour is okay as the same is done when this utility does
> vacuum for whole database.
IMV, the change is for the better. The whole point of
--analyze-in-stages is to get minimal statistics so that "good
enough" plans will be built for most queries to allow a production
database to be brought back on-line quickly, followed by generating
increasing granularity (which takes longer but should help ensure
"best plan") while the database is in use with the initial
statistics. Doing all three levels for one table before generating
the rough statistics for the others doesn't help with that, so I
see this change as fixing a bug. Is it feasible to break that part
out as a separate patch?
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company