From: | Martijn van Oosterhout <kleptog(at)svana(dot)org> |
---|---|
To: | Mark Dilger <pgsql(at)markdilger(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Fixed length data types issue |
Date: | 2006-09-10 20:21:13 |
Message-ID: | 20060910202113.GA27206@svana.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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(at)svana(dot)org> http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Fuhr | 2006-09-10 20:23:02 | Re: contrib uninstall scripts need some love |
Previous Message | Jeremy Kronuz | 2006-09-10 19:30:26 | Re: ISBN/ISSN/ISMN/EAN13 module |