On Mon, Dec 15, 2014 at 4:18 PM, Dilip kumar <dilip.ku...@huawei.com> wrote: > > On December 2014 17:31 Amit Kapila Wrote, > > > >Hmm, theoretically I think new behaviour could lead to more I/O in > > >certain cases as compare to existing behaviour. The reason for more I/O > > >is that in the new behaviour, while doing Analyze for a particular table at > > >different targets, in-between it has Analyze of different table as well, > > >so the pages in shared buffers or OS cache for a particular table needs to > > >be reloded again for a new target whereas currently it will do all stages > > >of Analyze for a particular table in one-go which means that each stage > > >of Analyze could get benefit from the pages of a table loaded by previous > > >stage. If you agree, then we should try to avoid this change in new > > >behaviour. > > > > I will work on this comment and post the updated patch.. >
One idea is to send all the stages and corresponding Analyze commands to server in one go which means something like "BEGIN; SET default_statistics_target=1; SET vacuum_cost_delay=0; Analyze t1; COMMIT;" "BEGIN; SET default_statistics_target=10; RESET vacuum_cost_delay; Analyze t1; COMMIT;" "BEGIN; RESET default_statistics_target; Analyze t1; COMMIT;" Now, still parallel operations in other backends could lead to page misses, but I think the impact will be minimized. > > I will move this patch to the latest commitfest. > By the way, I think this patch should be in Waiting On Author stage. With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
