Regarding TPC-H and widening, we can (and do currently for the one query we have implemented) cast the decimal back down to the correct precision after each multiplication, so I don’t think this is an issue. On the other hand, there are definitely things we can do to dynamically detect if decimals are narrow, and if so only update the lower half without too much overhead, so it wouldn’t be a huge loss if we didn’t add them.
Sasha > On Apr 23, 2022, at 7:14 PM, Jacques Nadeau <jacq...@apache.org> wrote: > > I'm generally -0.01 against narrow decimals. My experience in practice has > been that widening happens so quickly that they are little used and add > unnecessary complexity. For reference, the original Arrow code actually > implemented Decimal9 [1] and Decimal18 [2] but we removed both because of > this experience of complexity. (Good to note that we worked with them for > several years before the model was in the Arrow project before we came to > this conclusion.) > > One of the other commenters here spoke of the benefit to things like tpch. > I doubt this would be meaningful as I believe most (if not all) decimal > operations in TPCH would typically immediately widen to DECIMAL38. > > Another possible approach here might be to add DECIMAL18 to the spec and > see the usage with it (and how much value it really added) before > adding DECIMAL9. > > It's easy to add types to the spec, hard to remove them. > > [1] > https://github.com/apache/arrow/blob/fa5f0299f046c46e1b2f671e5e3b4f1956522711/java/vector/src/main/codegen/data/ValueVectorTypes.tdd#L66 > [2] > https://github.com/apache/arrow/blob/fa5f0299f046c46e1b2f671e5e3b4f1956522711/java/vector/src/main/codegen/data/ValueVectorTypes.tdd#L81 > > > >>
