Re: Fixed length data types issue

Tom Lane wrote:
> Bruce Momjian <bruce(at)momjian(dot)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
>