Amit Kapila <amit.kapil...@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 -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers