Обсуждение: fixed size columns

Поиск
Список
Период
Сортировка

fixed size columns

От
elein
Дата:
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?

thanks,
elein

--
----------------------------------------------------------------------------------------
elein@varlena.com     Database Consulting     www.varlena.com
              I have always depended on the [QA] of strangers.


Re: fixed size columns

От
Tom Lane
Дата:
elein <elein@sbcglobal.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


Re: fixed size columns

От
elein
Дата:
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@sbcglobal.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

--
----------------------------------------------------------------------------------------
elein@varlena.com     Database Consulting     www.varlena.com
              I have always depended on the [QA] of strangers.


Re: fixed size columns

От
Dennis Gearon
Дата:
If it's a many to many relationship, with just one ID in each of two columns from two, (or more) tables, then skinny
tablesare 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@sbcglobal.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
>
>


Re: fixed size columns

От
Manfred Koizar
Дата:
On Wed, 30 Apr 2003 12:28:27 -0700, elein <elein@sbcglobal.net> wrote:
>But are the fixed size varchars and characters
>being stored as varlenas with a 4byte overhead
>[...]?

Yes.  One of the reasons for this is that a fixed number of characters
does not necessarily mean a fixed number of bytes.

Servus
 Manfred