Jochen Erwied escribió:
> Maybe using 'numeric(19)' instead of bigint is an alternative. I actually
> don't know how these numbers are stored internally (some kind of BCD, or as
> base-100?), but IMHO they should be faster than strings, although not as
> fast as 'native' types.
base 1 in the
Thursday, February 4, 2010, 7:51:37 PM you wrote:
> it is an identifier and is always a number and is used in grouping and
> querying. I thought I would lose performance if it is text vs an
> integer/double field.
Maybe using 'numeric(19)' instead of bigint is an alternative. I actually
don't kno
On Thu, Feb 4, 2010 at 10:43 AM, Craig James wrote:
> Tory M Blue wrote:
>>
>> I have a column that is a bigint that needs to store integers up to 19
>> digits long. For the most part this works but we sometimes have
>> numbers that are greater than 9223372036854775807.
>> ...
>> I was thinking of
Tory M Blue escribió:
> I looked into the numeric data type, but the docs say that it can be slow.
It is slower than values that fit in a single CPU register, sure. Is it
slow enough that you can't use it? That's a different question. I'd
give it a try -- maybe it's not all that slow.
--
Alv
Tory M Blue wrote:
I have a column that is a bigint that needs to store integers up to 19
digits long. For the most part this works but we sometimes have
numbers that are greater than 9223372036854775807.
...
I was thinking of changing this to a real or double precision field,
but read in the doc
