>> 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. >> >> ken. >> > Does that mean you (i.e. Puppet DB) are already prepared to handle "anytype" > so that if we encode all numbers smaller than int64/binary64 as such, and > only larger values as a BigType then it would work by adding those as > alternative storage forms? > > Or do you expect a given named attribute to have a given storage type at all > times?
I presume you mean trying to force large numbers into an encoding, and expecting the edge applications to encode/decode? Yes this is possible, however it doesn't help the PuppetDB api consumers if say, a large number is encoded in some format that our query capabilities do not understand. Operators like > < won't work as expected as a point example, and consumers would be forced to do this decode on our response themselves. So its probably better to store numerics (as in arbitrary precision numbers) as numerics ... and take advantage of the db's native storage for that in this case, otherwise we'd have to encode/decode ourselves in the server (which we haven't done before) ... its far more optimal to push this work into PostgreSQL is my main point. And we could probably do this, the type in Java becomes a BigDecimal more or less as it moves out of JSON (and thats also basically the type you get back via JDBC when you query a numeric I believe). I would think if we had transport encoding issues (like mspack not supporting a larger type natively) we could decode before we store I guess. Thats an alternative. It means traversing the tree to find these cases and modifying them on the float perhaps. Things like zipper in clojure make this easier. Henrik, you keep mentioning msgpack won't support arbitrary storage, and I can't see it in the spec either. CBOR supports it (Bignums & Bigfloats), just wanted to point that out. I've been pondering the CBOR/msgpack story ever since I saw a split in the community around these extensive type issues, and looking for reasons to use either/or, thats all. Just something to keep an eye on. ken. -- 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/CAE4bNTnew6G8ostiHoJ9FXiec1Na2ZxGfUy42Qoxi0dxHOO%3DsA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
