From: | Denis Gasparin <denis(at)edistar(dot)com> |
---|---|
To: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Size comparison between a Composite type and an |
Date: | 2006-02-28 20:51:54 |
Message-ID: | 4404B7EA.5040008@edistar.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
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(at)edistar(dot)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
>
>
From | Date | Subject | |
---|---|---|---|
Next Message | Douglas McNaught | 2006-02-28 21:22:29 | Re: Size comparison between a Composite type and an |
Previous Message | Magnus Hagander | 2006-02-28 20:24:40 | Re: problem with windows xp sp2 and postgres-8.1.3 |