Another sub-question on this topic: I assume that if you don't add the property at all, then it add zero bytes to the record--correct? But if you add a fixed-size property (i.e. SHORT, INTERGER, LONG, etc.) to a record with its value explicitly set to NULL, does that take up the same amount of space as storing a value? I'm asking because of what happens next: If you later update that NULL property and set it to a non-NULL value, does that change the total size of the record or does it update "in place"?
On Fri, Jun 3, 2016 at 9:07 AM, Eric24 <e...@24x8.com> wrote: > PS - Also, it appears that OVERSIZE == 0 by default (per: select > expand(classes) from metadata:schema)? Is it a "factor" (i.e. > base-record-bytes * OVERSIZE) or a number of additional padding bytes to be > added? > > > On Friday, June 3, 2016 at 8:49:54 AM UTC-5, Eric24 wrote: >> >> 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> 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. >>>> 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 a topic in the > Google Groups "OrientDB" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/orient-database/Usr1haixKQc/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > orient-database+unsubscr...@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-database+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
