On Thursday, September 4, 2014 9:40:43 AM UTC-5, Ken Barber wrote: > > > > > Every Puppet value is potentially a Big now. What new cost is involved? > > I'm having trouble seeing how a database can deal efficiently with > Puppet's > > current implicit typing anyway, Big values notwithstanding. Without > > additional type information, it must be prepared for any given value to > be a > > boolean, an Integer, a float, or a 37kb string (among other > possibilities). > > Why do Big values present an especial problem in that regard? > > So right now, we have alternating native postgresql columns for the > bare types: text, biginteger, boolean, double precision. This provides > us with the ability to use the most optimal index for the type, and of > course avoid storing any more then we need to. As I mentioned at the > top of the thread, we specifically do not support arbitrary precision > decimals. > > At least one example in PostgreSQL, once you jump to say, a numeric > column type the performance characteristics and index efficiency > changes for the worse. Same goes for floats being stored in a numeric. > This is why you are better off avoiding the conversion until you > overflow and absolutely need a decimal usually. > >
Thanks, Ken. Could you devote a few words to how PuppetDB chooses which of those alternative columns to use for any particular value, and how it afterward tracks which one has been used? I'm also curious about whether index efficiency in PostgreSQL (as an example) takes a significant hit just from an index being defined on a Numeric/Decimal column or whether the impact depends strongly on the number of non-NULL values in that column. Additionally, I'm curious about how (or whether) the alternative column approach interacts with queries. Do selection predicates against Any type values typically need to consider multiple (or all) of the value columns? John -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/2cf06105-5fb8-494e-8b6d-126ee1b4d292%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
