Re: [HACKERS] varchar/char size - Mailing list pgsql-hackers

From Thomas G. Lockhart
Subject Re: [HACKERS] varchar/char size
Date
Msg-id 34B63942.9FBBCB2B@alumni.caltech.edu
Whole thread Raw
In response to varchar/char size  (Bruce Momjian <maillist@candle.pha.pa.us>)
List pgsql-hackers
> > Does someone want to remind me why we allocate the full size for char()
> > and varchar(), when we really can just allocate the size of the given
> > string?
> >
> > I relize char() has to be padded, but why varchar()?
> >
> > In my experience, char() is full size as defined by create, and
> > varchar() is the the size of the actual data in the field, like text,
> > but with a pre-defined limit.
>
> Is CHAR padded on disk? Of course it should be padded for
> representation, but for storage, couldn't it be stored just like
> TEXT or VARCHAR? Before storing, it could be trimmed, and when
> read from storage, it could be padded with spaces on the right.

My CA/Ingres Admin manual points out that there is a tradeoff between
compressing tuples to save disk storage and the extra processing work
required to uncompress for use. They suggest that the only case where you
would consider compressing on disk is when your system is very I/O bound,
and you have CPU to burn.

The default for Ingres is to not compress anything, but you can specify
compression on a table-by-table basis.

btw, char() is a bit trickier to handle correctly if you do compress it on
disk, since trailing blanks must be handled correctly all the way through.
For example, you would want 'hi' = 'hi   ' to be true, which is not a
requirement for varchar().

                                                        - Tom


pgsql-hackers by date:

Previous
From: "Vadim B. Mikheev"
Date:
Subject: Re: subselects
Next
From: Zeugswetter Andreas DBT
Date:
Subject: column labels now with obligatory 'as'