On Thu, Apr 3, 2014 at 5:33 PM, Gilad Chaplik <gchap...@redhat.com> wrote:
> *From: *"Liran Zelkha" <liran.zel...@gmail.com> > *To: *"Gilad Chaplik" <gchap...@redhat.com> > *Cc: *"Omer Frenkel" <ofren...@redhat.com>, "Eli Mesika" < > emes...@redhat.com>, "engine-devel" <engine-devel@ovirt.org> > *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. 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) > On Apr 3, 2014 5:18 PM, "Gilad Chaplik" <gchap...@redhat.com> wrote: > >> ----- Original Message ----- >> > From: "Liran Zelkha" <liran.zel...@gmail.com> >> > To: "Gilad Chaplik" <gchap...@redhat.com> >> > Cc: "Eli Mesika" <emes...@redhat.com>, "engine-devel" < >> engine-devel@ovirt.org> >> > 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" <gchap...@redhat.com> wrote: >> > >> > > ----- Original Message ----- >> > > > From: "Liran Zelkha" <liran.zel...@gmail.com> >> > > > To: "Eli Mesika" <emes...@redhat.com> >> > > > Cc: "Gilad Chaplik" <gchap...@redhat.com>, "engine-devel" < >> > > engine-devel@ovirt.org> >> > > > 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 <emes...@redhat.com> >> wrote: >> > > > >> > > > > >> > > > > >> > > > > ----- Original Message ----- >> > > > > > From: "Gilad Chaplik" <gchap...@redhat.com> >> > > > > > To: "Yair Zaslavsky" <yzasl...@redhat.com> >> > > > > > Cc: "engine-devel" <engine-devel@ovirt.org> >> > > > > > Sent: Thursday, April 3, 2014 4:00:25 PM >> > > > > > Subject: Re: [Engine-devel] vds_dynamic refactor >> > > > > > >> > > > > > ----- Original Message ----- >> > > > > > > From: "Yair Zaslavsky" <yzasl...@redhat.com> >> > > > > > > To: "Liran Zelkha" <liran.zel...@gmail.com> >> > > > > > > Cc: "Gilad Chaplik" <gchap...@redhat.com>, "engine-devel" >> > > > > > > <engine-devel@ovirt.org> >> > > > > > > Sent: Thursday, April 3, 2014 2:12:59 PM >> > > > > > > Subject: Re: [Engine-devel] vds_dynamic refactor >> > > > > > > >> > > > > > > >> > > > > > > >> > > > > > > ----- Original Message ----- >> > > > > > > > From: "Liran Zelkha" <liran.zel...@gmail.com> >> > > > > > > > To: "Gilad Chaplik" <gchap...@redhat.com> >> > > > > > > > Cc: "engine-devel" <engine-devel@ovirt.org> >> > > > > > > > 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 < >> > > gchap...@redhat.com> >> > > > > > > > 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 >> > > > > > > > > Engine-devel@ovirt.org >> > > > > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel >> > > > > > > > > >> > > > > > > > >> > > > > > > > _______________________________________________ >> > > > > > > > Engine-devel mailing list >> > > > > > > > Engine-devel@ovirt.org >> > > > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel >> > > > > > > > >> > > > > > > >> > > > > > _______________________________________________ >> > > > > > Engine-devel mailing list >> > > > > > Engine-devel@ovirt.org >> > > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel >> > > > > > >> > > > > _______________________________________________ >> > > > > Engine-devel mailing list >> > > > > Engine-devel@ovirt.org >> > > > > http://lists.ovirt.org/mailman/listinfo/engine-devel >> > > > > >> > > > >> > > >> > >> > >
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel