Hi > How does OVERSIZE relate to the cluster parameter RECORD_GROW_FACTOR? This cluster parameter is deprecated and not used. >What is actually stored on disk when a new record is written (per-record and per-property)? We save record when we change property inside the record. >What overhead is incurred by storing a dynamic non-schema-defined property (i.e. how is the name of the property stored) The record is more compact if you store schema defined property than if you store schema undefined property because instead of names of fields we use ids of properties. >Does it incur any per-record overhead to define a non-mandatory property in the schema if that property has not been assigned a value? Do you mean whether we add additional information to record if field is absent in record itself but defined in schema, do not you ? No, we do not add any overhead.
On Fri, Jun 3, 2016 at 4:00 PM Eric24 <[email protected]> wrote: > Luca (or someone from ODB)--can you provide some additional details on > this? If it's in the documentation, I can't find it, and I think these are > important things to know: > > 1. How does OVERSIZE relate to the cluster > parameter RECORD_GROW_FACTOR? > 2. What is actually stored on disk when a new record is written > (per-record and per-property)? > 3. What overhead is incurred by storing a dynamic non-schema-defined > property (i.e. how is the name of the property stored)? > 4. Does it incur any per-record overhead to define a non-mandatory > property in the schema if that property has not been assigned a value? > > > On Monday, May 30, 2016 at 9:32:28 AM UTC-5, l.garulli wrote: > >> Hi guys, >> Oversize is per class setting, but is computed per record. So if you do >> this: >> >> INSERT INTO Employee set name = 'Luca' >> >> And the record is, for example, 100 bytes, with oversize 2, it means >> OrientDB will store 200 bytes with 100 bytes padding. Any further update >> where the new size is <= 200 the record is just updated, otherwise will be >> stored on a new space (with space to reuse). >> >> In the future we could change the underlying storage, so this oversize >> technique could be ignored. I suggest you to check with different settings >> if oversize takes pros to your use case or not. >> >> >> >> Best Regards, >> >> Luca Garulli >> Founder & CEO >> OrientDB <http://orientdb.com/> >> >> >> On 28 May 2016 at 19:35, 'scott molinari' via OrientDB < >> [email protected]> wrote: >> > All questions I'd like to know the answer to too. >>> >>> Scott >>> >> -- >>> >>> --- >>> You received this message because you are subscribed to the Google >>> Groups "OrientDB" group. >>> >> To unsubscribe from this group and stop receiving emails from it, send an >>> email to [email protected]. >>> >> >>> For more options, visit https://groups.google.com/d/optout. >>> >> -- > > --- > You received this message because you are subscribed to the Google Groups > "OrientDB" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- Best regards, Andrey Lomakin, R&D lead. OrientDB Ltd twitter: @Andrey_Lomakin linkedin: https://ua.linkedin.com/in/andreylomakin blogger: http://andreylomakin.blogspot.com/ -- --- You received this message because you are subscribed to the Google Groups "OrientDB" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
