On Fri, Jan 2, 2015 at 8:34 PM, Kevin Grittner <kgri...@ymail.com> wrote: > > 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? >
Currently as the patch stands the fix (or new behaviour) is only implemented for the multiple jobs option, however to fix this in base code a separate patch is required. With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
