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@xxxxxxxxxxx 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