On Mon, Dec 15, 2014 at 4:18 PM, Dilip kumar <
dilip.kumar@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.
