Re: [HACKERS] varchar/char size

Поиск
Список
Период
Сортировка
От Thomas G. Lockhart
Тема Re: [HACKERS] varchar/char size
Дата
Msg-id 34B63942.9FBBCB2B@alumni.caltech.edu
обсуждение исходный текст
Ответ на varchar/char size  (Bruce Momjian <maillist@candle.pha.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: "Vadim B. Mikheev"
Дата:
Сообщение: Re: subselects
Следующее
От: Zeugswetter Andreas DBT
Дата:
Сообщение: column labels now with obligatory 'as'