Re: Size comparison between a Composite type and an
От | Denis Gasparin |
---|---|
Тема | Re: Size comparison between a Composite type and an |
Дата | |
Msg-id | 4404B7EA.5040008@edistar.com обсуждение исходный текст |
Ответ на | Re: Size comparison between a Composite type and an (Douglas McNaught <doug@mcnaught.org>) |
Ответы |
Re: Size comparison between a Composite type and an
Re: Size comparison between a Composite type and an |
Список | 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@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 > >
В списке pgsql-general по дате отправления: