Tom Lane wrote:
Bruce Momjian <[EMAIL PROTECTED]> 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


---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

Reply via email to