[prev in list] [next in list] [prev in thread] [next in thread] 

List:       postgresql-general
Subject:    Re: [GENERAL] Size comparison between a Composite type and an
From:       Denis Gasparin <denis () edistar ! com>
Date:       2006-02-28 20:51:54
Message-ID: 4404B7EA.5040008 () edistar ! com
[Download RAW message or body]

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


---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend
[prev in list] [next in list] [prev in thread] [next in thread]