Re: Fixed length data types issue

Tom Lane wrote:
> Bruce Momjian <bruce@momjian.us> writes:
>> No one has mentioned that we page value on disk to match the CPU
>> alignment.  This is done for efficiency, but is not strictly required.
> 
> 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?

I would be particularly interested in the creation of a 24-bit integer 
if it could pack into only three bytes.  (If the layout forces an extra 
byte of padding per integer, the advantage is lost.)

For argument sake, if I created a contrib extension called "int3" which 
stored 24-bit integers, in the int3.source file I could write:

CREATE TYPE int3 (internallength = 3,input = int3_in,output = int3_out,alignment = <ALIGNMENT>
);

And then have sed replace <ALIGNMENT> with either "char" or "int4" 
depending on the architecture.

Is there a reason this wouldn't work?

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.

mark

> The only way we could pack stuff without alignment is to go over to the
> idea that memory and disk representations are different --- where in
> this case the "conversion" might just be a memcpy to a known-aligned
> location.  The performance costs of that seem pretty daunting, however,
> especially when you reflect that simply stepping over a varlena field
> would require memcpy'ing its length word to someplace.
> 
>             regards, tom lane
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Have you searched our list archives?
> 
>                http://archives.postgresql.org
>