----- 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. [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
