[DNM] col/coldata: batch allocate big.Int coefficients for Decimals vectors

[nvanbenschoten]

Related to #57593. Not a full replacement, but maybe a medium-term mitigation.

This commit updates defaultColumnFactory.MakeColumn to batch allocate the coefficients of each decimal in a Decimals vector.

Each Decimal maintains (through an embedded big.Int) an internal reference to a variable-length coefficient which is represented by a []big.Word. This commit attempts to minimize heap allocations by pre-allocating a single large []big.Word and distributing chunks of this slice to each Decimal in a Decimals vector. big.Int will avoid re-allocating unless its coefficient unless it is provided with a coefficient that exceeds the initial capacity. We set this capacity to accommodate any coefficient that would fit in a 64-bit integer (i.e. up to 2^64).

On the read-only portion of the TPC-E (77% of the full workload, in terms of txn mix), this change has a significant impact on total heap allocations. Before the change, math/big.nat.make was responsible for 51.07% of total heap allocations:

After the change, math/big.nat.make is responsible for only 1.1% of total heap allocations:

That equates to roughly a 50% reduction in heap allocations.

---

The PR also contains a second commit that does something similar for non-vectorized execution. That commit needs more work and can be split from the first commit if we'd like.

[cockroach-teamcity]

This change is 

[nvanbenschoten]

After thinking about this a bit further, I wonder whether we should be pushing this optimization into apd.Decimal.

I recall @mjibson expressing caution when discussing the "inline" representation that other similar libraries use (e.g. ericlagergren.decimal.Big.compact). I believe his concern was that the optimization would leak out across the library and would lead to more complex, error-prone code. Based on the number of references to "compact" in the business logic of https://github.com/ericlagergren/decimal/blob/aca2edc11f73e28a0e93d592cc6c3de4a352a81c/big.go, I can see where he was coming from.

If that was the main concern, then the approach used in this PR of inlining the big.Int's Word slice might be worth pursuing. This is a much more targeted optimization, as it still defers all arithmetic on the decimal's coefficient to big.Int. However, it provides the same compact memory representation, while trading off only marginal performance (would need validation). The idea would be to change apd.Decimal to look something like:

type Decimal struct {
	Form        Form
	Negative    bool
	Exponent    int32
	Coeff       big.Int
+	coeffInline [1]big.Word
}

+// lazyInit lazily initializes a zero Decimal value.
+func (d *Decimal) lazyInit() {
+	if d.Coeff.Bits() == nil {
+		d.Coeff.SetBits(d.coeffInline[:0])
+	}
+}

We could then add d.lazyInit() calls to the prelude of apd.Decimal's mutable methods. I think that's all that would be needed. Then we wouldn't need to leave any of this up in cockroach code.

If I get the chance, I'll try to play around with this idea.

---

Also, while we're at it, we should change apd.Decimal.Form to use an int8 as its base type. That should save a word. Or put another way, it should offset the size of coeffInline, making the other optimization free.