Re: Fixed length data types issue

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.

In response to

Responses

Browse pgsql-hackers by date

  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