Re: Fixed length data types issue - Mailing list pgsql-hackers

From Martijn van Oosterhout
Subject Re: Fixed length data types issue
Date
Msg-id 20060910202113.GA27206@svana.org
Whole thread Raw
In response to Re: Fixed length data types issue  (Mark Dilger <pgsql@markdilger.com>)
Responses Re: Fixed length data types issue  (Mark Dilger <pgsql@markdilger.com>)
List pgsql-hackers
On Sun, Sep 10, 2006 at 11:55:35AM -0700, Mark Dilger wrote:
> >Well, it is unless you are willing to give up support of non-Intel CPUs;
> >most other popular chips are strict about alignment, and will fail an
> >attempt to do a nonaligned fetch.
>
> Intel CPUs are detectable at compile time, right?  Do we use less
> padding in the layout for tables on Intel-based servers?  If not, could we?

Intel CPUs may not complain about unaligned reads, they're still
inefficient. Internally it does two aligned reads and rearranges the
bytes. On other architechtures the OS can emulate that but postgres
doesn't use that for obvious reasons.

> For the example schema which started this thread, a contrib extension
> for ascii fields could be written, with types like ascii1, ascii2,
> ascii3, and ascii4, each with implicit upcasts to text.  A contrib for
> int1 and uint1 could be written to store single byte integers in a
> single byte, performing math on them correctly, etc.

The problem is that for each of those ascii types, to actually use them
they would have to be converted, which would amount to allocating some
memory, copying and adding a length header. At some point you have to
wonder whether you're actually saving anything.

Have a nice day,
--
Martijn van Oosterhout   <kleptog@svana.org>   http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.

pgsql-hackers by date:

Previous
From: "Jeremy Kronuz"
Date:
Subject: Re: [PATCHES] ISBN/ISSN/ISMN/EAN13 module
Next
From: Michael Fuhr
Date:
Subject: Re: contrib uninstall scripts need some love