On Thu, Apr 3, 2014 at 8:40 PM, Gilad Chaplik <[email protected]> wrote:
> ----- Original Message ----- > > From: "Liran Zelkha" <[email protected]> > > To: "Gilad Chaplik" <[email protected]> > > Cc: "Omer Frenkel" <[email protected]>, "Eli Mesika" < > [email protected]>, "engine-devel" <[email protected]>, > > [email protected] > > Sent: Thursday, April 3, 2014 7:51:39 PM > > Subject: Re: [Engine-devel] vds_dynamic refactor > > > > On Thu, Apr 3, 2014 at 5:33 PM, Gilad Chaplik <[email protected]> > wrote: > > > > > *From: *"Liran Zelkha" <[email protected]> > > > *To: *"Gilad Chaplik" <[email protected]> > > > *Cc: *"Omer Frenkel" <[email protected]>, "Eli Mesika" < > > > [email protected]>, "engine-devel" <[email protected]> > > > *Sent: *Thursday, April 3, 2014 5:27:56 PM > > > *Subject: *Re: [Engine-devel] vds_dynamic refactor > > > > > > True but that's no reason to have a bad schema > > > > > > I'm open to new ideas and truly want to understand what is bad? > > > > > 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. > > What about creating the VDS list in the db. i.e. your patch [1] about > constructing VDS objects in the engine, should occur in the db within a SP, > and should be transparent to the server. that will solve the multiple table > join. > The joins are happening on the server. We have a VDS view that brings in information from many tables and we retrieve rows from it all the time. Just run an explain on a select * from vds and see for yourself. > > [1] http://gerrit.ovirt.org/#/c/21662/ > > > 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) > > > > - As omer stated in a separate thread static stores users config. > - Updating status/pending resources in statistics sounds very racy. > > saying that, I think I have a valid argument for vds_on_boot table. > > Thanks, > Gilad. > > > > > On Apr 3, 2014 5:18 PM, "Gilad Chaplik" <[email protected]> wrote: > > > > > >> ----- Original Message ----- > > >> > From: "Liran Zelkha" <[email protected]> > > >> > To: "Gilad Chaplik" <[email protected]> > > >> > Cc: "Eli Mesika" <[email protected]>, "engine-devel" < > > >> [email protected]> > > >> > Sent: Thursday, April 3, 2014 5:16:51 PM > > >> > Subject: Re: [Engine-devel] vds_dynamic refactor > > >> > > > >> > Don't go down that road. Status shouldn't be saved in the db. > > >> > But anyway statistics is rapidly changing. So it fits... > > >> > > >> First let's have a notion of caching, then notion of shared caching, > then > > >> I can start thinking of not going down that road... > > >> > > >> > On Apr 3, 2014 5:14 PM, "Gilad Chaplik" <[email protected]> > wrote: > > >> > > > >> > > ----- Original Message ----- > > >> > > > From: "Liran Zelkha" <[email protected]> > > >> > > > To: "Eli Mesika" <[email protected]> > > >> > > > Cc: "Gilad Chaplik" <[email protected]>, "engine-devel" < > > >> > > [email protected]> > > >> > > > Sent: Thursday, April 3, 2014 4:36:07 PM > > >> > > > Subject: Re: [Engine-devel] vds_dynamic refactor > > >> > > > > > >> > > > I would be happy if we can lose vds_dynamic all together, and > just > > >> keep > > >> > > > vds_static and vds_statistics. Our performance will be happy > too ;-) > > >> > > > > > >> > > > > >> > > @Liran, status and pending fields are very fragile ones, IMO need > > >> separate > > >> > > table. > > >> > > @Eli, iirc, you don't have a problem with adding more tables :-) > > >> > > > > >> > > > > > >> > > > On Thu, Apr 3, 2014 at 4:33 PM, Eli Mesika <[email protected]> > > >> wrote: > > >> > > > > > >> > > > > > > >> > > > > > > >> > > > > ----- Original Message ----- > > >> > > > > > From: "Gilad Chaplik" <[email protected]> > > >> > > > > > To: "Yair Zaslavsky" <[email protected]> > > >> > > > > > Cc: "engine-devel" <[email protected]> > > >> > > > > > Sent: Thursday, April 3, 2014 4:00:25 PM > > >> > > > > > Subject: Re: [Engine-devel] vds_dynamic refactor > > >> > > > > > > > >> > > > > > ----- Original Message ----- > > >> > > > > > > From: "Yair Zaslavsky" <[email protected]> > > >> > > > > > > To: "Liran Zelkha" <[email protected]> > > >> > > > > > > Cc: "Gilad Chaplik" <[email protected]>, "engine-devel" > > >> > > > > > > <[email protected]> > > >> > > > > > > Sent: Thursday, April 3, 2014 2:12:59 PM > > >> > > > > > > Subject: Re: [Engine-devel] vds_dynamic refactor > > >> > > > > > > > > >> > > > > > > > > >> > > > > > > > > >> > > > > > > ----- Original Message ----- > > >> > > > > > > > From: "Liran Zelkha" <[email protected]> > > >> > > > > > > > To: "Gilad Chaplik" <[email protected]> > > >> > > > > > > > Cc: "engine-devel" <[email protected]> > > >> > > > > > > > Sent: Thursday, April 3, 2014 2:04:29 PM > > >> > > > > > > > Subject: Re: [Engine-devel] vds_dynamic refactor > > >> > > > > > > > > > >> > > > > > > > Why not move it to vds_static? > > >> > > > > > > > > >> > > > > > > +1 on Liran's comment. > > >> > > > > > > >> > > > > +1 as well , vds_static is the place for that > > >> > > > > > > >> > > > > > > I would prefer not to add more complexity to the vds > tables > > >> > > family. > > >> > > > > > > Such complexity may effect performs of queries/views. > > >> > > > > > > If you wish, you can create a view on top of vds_static > named > > >> > > > > vds_on_boot > > >> > > > > > > for > > >> > > > > > > querying of vds on boot info. > > >> > > > > > > > > >> > > > > > > Yair > > >> > > > > > > > >> > > > > > That means moving almost all of vds_dynamic into vds_static > > >> except of > > >> > > > > memory, > > >> > > > > > pending resources and status (maybe more but not much); > > >> > > > > > and there will not be any db separation between user input > and > > >> > > on_boot > > >> > > > > data. > > >> > > > > > > >> > > > > Why we should have such separation ? > > >> > > > > > > >> > > > > > > > >> > > > > > Thanks, > > >> > > > > > Gilad. > > >> > > > > > > > >> > > > > > > > > >> > > > > > > > > > >> > > > > > > > > > >> > > > > > > > On Thu, Apr 3, 2014 at 2:00 PM, Gilad Chaplik < > > >> > > [email protected]> > > >> > > > > > > > wrote: > > >> > > > > > > > > > >> > > > > > > > > Hi list, > > >> > > > > > > > > > > >> > > > > > > > > I propose to split vds_dynamic table into 2 tables: > > >> > > > > > > > > - vds_dynamic > > >> > > > > > > > > - vds_on_boot > > >> > > > > > > > > We need a place to put all non-dynamic data that gets > > >> updated > > >> > > once > > >> > > > > the > > >> > > > > > > > > host is booted, and I think dynamic isn't the place > for > > >> it. > > >> > > > > > > > > In first phase we will put there NUMA host topoplogy, > but > > >> > > later on > > >> > > > > > > > > migrate > > >> > > > > > > > > all non-dynamic host data (cpu, os, etc.). > > >> > > > > > > > > > > >> > > > > > > > > thoughts? > > >> > > > > > > > > > > >> > > > > > > > > Thanks, > > >> > > > > > > > > Gilad. > > >> > > > > > > > > _______________________________________________ > > >> > > > > > > > > Engine-devel mailing list > > >> > > > > > > > > [email protected] > > >> > > > > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > >> > > > > > > > > > > >> > > > > > > > > > >> > > > > > > > _______________________________________________ > > >> > > > > > > > Engine-devel mailing list > > >> > > > > > > > [email protected] > > >> > > > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > >> > > > > > > > > > >> > > > > > > > > >> > > > > > _______________________________________________ > > >> > > > > > Engine-devel mailing list > > >> > > > > > [email protected] > > >> > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > >> > > > > > > > >> > > > > _______________________________________________ > > >> > > > > Engine-devel mailing list > > >> > > > > [email protected] > > >> > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > >> > > > > > > >> > > > > > >> > > > > >> > > > >> > > > > > > > > >
_______________________________________________ Devel mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/devel
