Re: TODO : Allow parallel cores to be used by vacuumdb [ WIP ]

From: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
To: Dilip kumar <dilip(dot)kumar(at)huawei(dot)com>
Cc: Magnus Hagander <magnus(at)hagander(dot)net>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Jan Lentfer <Jan(dot)Lentfer(at)web(dot)de>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Sawada Masahiko <sawada(dot)mshk(at)gmail(dot)com>, Euler Taveira <euler(at)timbira(dot)com(dot)br>
Subject: Re: TODO : Allow parallel cores to be used by vacuumdb [ WIP ]
Date: 2014-12-19 11:10:58
Message-ID: CAA4eK1KYVSjxFZx6e0SfZeyFu1fFh-gmPxQV_bC6EALYEAFWAw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Dec 15, 2014 at 4:18 PM, Dilip kumar <dilip(dot)kumar(at)huawei(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Chris Butler 2014-12-19 11:16:14 Re: Updated libpq5 packages cause connection errors on postgresql 9.2
Previous Message Christoph Berg 2014-12-19 10:52:43 Re: Updated libpq5 packages cause connection errors on postgresql 9.2