Re: fixed size columns

If it's a many to many relationship, with just one ID in each of two columns from two, (or more) tables, then skinny tables are just the ticket. :-)

elein wrote:
> Thanks. That is most of what I wanted to know.
> Alignment is by field on 4 byte boundaries
> or possibly 8 bytes depending on the machine.
>
> I knew long, skinny tables were bad. (I didn't
> design this one :-\ I just have to deal with it.)
>
> But are the fixed size varchars and characters
> being stored as varlenas with a 4byte overhead
> or just as characters with or without the EOS?
>
> varcharout() converts the varlena to a string.
> This is the function used to provide the data which
> is eventually written to disk, isn't it? If so,
> the answer to my question is that they are being
> stored with one byte overhead.
>
> Please confirm or correct me.
>
> thanks!
>
> elein
>
> On Tuesday 29 April 2003 21:55, Tom Lane wrote:
>
>>elein <elein(at)sbcglobal(dot)net> writes:
>>
>>>I have a very long, very narrow table that is taking up a few gigabytes.
>>>The table is defined with varchar(n) fields and some character(n) fields.
>>>I am assuming that the majority of all fields are filled.
>>>
>>>Are these rows being stored on disk as aligned varlenas? Can I squish out
>>>some space by arranging the columns to groups of 8 bytes? Or is each
>>>column aligned separately on a new 8 byte boundary? Or is this a futile
>>>exercise?
>>
>>Those fields will be aligned on 4-byte boundaries within a row.
>>Depending on your machine architecture, the total length of a row might
>>be constrained to an 8-byte multiple or a 4-byte multiple.
>>
>>My guess is that you'd be spending your time more productively by
>>figuring a way to make the table less narrow. PG's 28-or-more-byte
>>overhead per row is usually bad news for narrow table designs, long
>>before you worry about alignment.
>>
>> regards, tom lane
>
>