On Sun, Apr 6, 2014 at 3:18 PM, Gilad Chaplik <[email protected]> wrote:
> ----- Original Message ----- > > From: "Itamar Heim" <[email protected]> > > To: "Liran Zelkha" <[email protected]> > > Cc: "Gilad Chaplik" <[email protected]>, [email protected], > "engine-devel" <[email protected]> > > Sent: Sunday, April 6, 2014 11:33:12 AM > > Subject: Re: [Engine-devel] vds_dynamic refactor > > > > On 04/06/2014 11:32 AM, Liran Zelkha wrote: > > > > > > > > > > > > On Sun, Apr 6, 2014 at 11:22 AM, Itamar Heim <[email protected] > > > <mailto:[email protected]>> wrote: > > > > > > On 04/03/2014 07:51 PM, Liran Zelkha wrote: > > > > > > The problem is with both updates and selects. > > > For selects - to get all the information for the VDS we have > > > multiple > > > joins. Adding another one will hurt performance even more. > > > For updates - we have vds_static thats hardly changed. > > > vds_statistics > > > that changes all the time. vds_dynamic is not changed allot - > but > > > is > > > updated all the time because of the status. I think it's best > to > > > split > > > it to the two existing tables (BTW - relevant for VM as well) > > > > > > > > > but we don't update it unless the status has changed, which is a > > > rare occurance? > > > > > > Actually - no. We can definitely see times we are updating vds_dynamic > > > with no reason at all. I tried to create patches for that - but it > > > happens from many different places in the code. > > > > what would be updated vds_dyanmic for status not originating in update > > run time info? > > We have separate DB flows for that (updateStatus and > updatePartialVdsDynamicCalc and more in VdsDynamicDAODbFacadeImpl). > A question: do you know if we update status in updateVdsDynamic? :-) not > sure but I found a possible race for pending resources (cpu, mem), LOL :-) > > I think we do but not sure. Will check. > Still holds my original thought for having vds_on_boot. > > > Let's talk f2f on Tuesday?
_______________________________________________ Devel mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/devel
