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