Hi Doug.
I considered also the numeric type. In that case if the number is of 32
digits the storage size is of 2*8 + 8 = 24 bytes.
If i store it using a composite data type of two bigints the size is 2*8
+ composite data structure overhead bytes.
If the composite data type has 4 bytes overhead, I save 4 bytes for each
number... that is important because I must store many many numbers.
Performance speaking, the numeric type can be indexed?
In the case of composite data types, I must create an operator class for
indexing the fields of that type...
What is the performance gap between indexed numeric and composite?
Thank you,
Denis
Douglas McNaught wrote:
> denis@edistar.com writes:
>
>
>> I need to store very large integers (more of 30 digits).
>>
>
> Er,
>
> What's wrong with the NUMERIC type? That can go up to hundreds of
> digits.
>
> -Doug
>
> ---------------------------(end of broadcast)---------------------------
> TIP 9: In versions below 8.0, the planner will ignore your desire to
> choose an index scan if your joining column's datatypes do not
> match
>
>
