Re: Size comparison between a Composite type and an

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

In response to

Responses

Browse pgsql-general by date

  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