Re: Size comparison between a Composite type and an

On Tue, Feb 28, 2006 at 09:51:54PM +0100, Denis Gasparin wrote:
> 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.

Well, that's an assumption. There was a time where composite types had
a 10+ byte overhead. I'm not sure what the current overhead is but I'm
fairly sure it's more than 4.

> Performance speaking, the numeric type can be indexed?

Ofcourse.

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

I think numeric will win easily. a few other things:

1. Alignment will probably eat any small savings you make
2. Numeric will take less space for small numbers
3. You have to make functions to index these composite type. Unless you
write them directly in C, the numeric code will win just on the
overhead of whatever other language you use to do it.

The best performance might come from making your own int16 type but all
this seems like premature optimisation to me. How about you start with
numeric and optimise when you see there's an actual problem.

Have a nice day,
--
Martijn van Oosterhout <kleptog(at)svana(dot)org> http://svana.org/kleptog/
> Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a
> tool for doing 5% of the work and then sitting around waiting for someone
> else to do the other 95% so you can sue them.