Thanks Andrey! Let me clarify a few of your answers... So RECORD_GROWTH_FACTOR is deprecated? I assume that applies to RECORD_OVERFLOW_GROW_FACTOR too? (I sure wish the documentation could be kept up-to-date--ODB is a very complex system, which is what makes it so appealing, but lack of complete documentation is so frustrating!)
Regarding "What is actually stored on disk when a new record is written (per-record and per-property)?", what I'm asking about is overhead that's actually written to the disk when you save a record, per-record (i.e. a record with a single INTEGER property takes up more disk space than the 4 bytes of the INTEGER--what else is there as "overhead"?) and per-property (i.e. does every property itself take up only the bytes needed to store its actual data? Probably not. So what else is written, by property type, as "overhead"? For example, you say you use IDs of schema-defined properties--so how many bytes is a property ID? Also, do some property types have more overhead than just the ID?) --Eric On Friday, June 3, 2016 at 8:25:41 AM UTC-5, Andrey Lomakin wrote: > > 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 <er...@24x8.com <javascript:>> > 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 < >>> orient-...@googlegroups.com> 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 orient-databa...@googlegroups.com. >>>> >>> >>>> 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 orient-databa...@googlegroups.com <javascript:>. >> 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 orient-database+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
