Re: Reduce NUMERIC size by 2 bytes, reduce max length to 508

Tom Lane wrote:
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> > The limit seems to be around 150k digits:
>
> It's exactly 10^(128K), as I've mentioned more than once.
>
> > So, with the patch, the storage length is going from 1000 digits to 508,
> > but the computational length is reduced from around 150k digits to 508.
> > Now, because no one has complained about the 1000-digit limit, it is
> > unlikely that anyone is doing calculations over 1000 or the would have
> > had problems with storing the value,
>
> Only if they declared their columns as numeric(N) and not just plain
> unconstrained numeric. Not to mention the possibility that they're
> doing the same thing you just did, ie computing values and returning
> them to the client without ever storing them in a table. So I don't
> think the above reasoning is defensible.
>
> > Not only does 4000! not work, but 400! doesn't even work. I just lost
> > demo "wow" factor points!
>
> It looks like the limit would be about factorial(256).
>
> The question remains, though, is this computational range good for
> anything except demos?

I can say that the extended range is good for finding *printf problems. ;-)

Let me also add that as far as saving disk space, this is the _big_
improvement on the TODO list:

* Merge xmin/xmax/cmin/cmax back into three header fields

Before subtransactions, there used to be only three fields needed to
store these four values. This was possible because only the current
transaction looks at the cmin/cmax values. If the current transaction
created and expired the row the fields stored where xmin (same as
xmax), cmin, cmax, and if the transaction was expiring a row from a
another transaction, the fields stored were xmin (cmin was not
needed), xmax, and cmax. Such a system worked because a transaction
could only see rows from another completed transaction. However,
subtransactions can see rows from outer transactions, and once the
subtransaction completes, the outer transaction continues, requiring
the storage of all four fields. With subtransactions, an outer
transaction can create a row, a subtransaction expire it, and when the
subtransaction completes, the outer transaction still has to have
proper visibility of the row's cmin, for example, for cursors.

One possible solution is to create a phantom cid which represents a
cmin/cmax pair and is stored in local memory. Another idea is to
store both cmin and cmax only in local memory.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073