Re: [HACKERS] varchar/char size

Поиск
Список
Период
Сортировка
От Bruce Momjian
Тема Re: [HACKERS] varchar/char size
Дата
Msg-id 199801091558.KAA27852@candle.pha.pa.us
обсуждение исходный текст
Ответ на Re: [HACKERS] varchar/char size  (Mattias Kregert <matti@algonet.se>)
Ответы Re: [HACKERS] varchar/char size  (The Hermit Hacker <scrappy@hub.org>)
Список pgsql-hackers
>
> Bruce Momjian wrote:
> >
> > 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.

Well, traditionally, CHAR() is fixed length, and VARCHAR() is variable.
This is how Ingres and Informix handle it.

There is very little difference in the types because internally they are
handled the same.  The only difference is when we need to specify a max
length, we do that with those types.

>
> Btw, why is VARCHAR not simply an alias for TEXT, with maxlen added?
> Shouldn't these types be the same internally, but with maxlen checked
> for VARCHAR in the parser and maxlen set to "infinite"(-1?) for TEXT?
> Or perhaps CHAR could be put into the same type also?

Right now we do some of the special processing using the OID of VARCHAR
and BPCHAR, which is char().  We would have to generalize the length
idea for each type, which is not hard to do.

>
> If we have a type called VARTEXT(int maxLen, bool doPaddingProcessing):
>
> VARCHAR(10) becomes VARTEXT(10, false)    // 10 chars, no padding
> TEXT becomes VARTEXT(0, false)        // infinite length, no padding
> CHAR(10) becomes VARTEXT(10, true)    // 10 chars, padded
>
> Would not this be easier to handle than three different types? This
> type stuff would be handled in the parser. There would be only one
> storage function, which could do any kind of coding to make the VARTEXT
> take as little space as possible on disk.
> Perhaps it would (in some cases) be good to have the possibility to
> specify compression of the text. That could be another bool attribute
> to VARTEXT, used by "COMPRESSED VARCHAR()" or "COMPRESSED TEXT" so that
> people can squeeze the maximum out of their disk space.
>
> A related question: Is it possible to store tuples over more than one
> block? Would it be possible to split a big TEXT into multiple blocks?

I don't know why it is not possible, but I suppose it goes to the
internal workings of PostgreSQL and how rows are added and modified.

--
Bruce Momjian
maillist@candle.pha.pa.us

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Peter T Mount
Дата:
Сообщение: Re: [HACKERS] grant broken
Следующее
От: darrenk@insightdist.com (Darren King)
Дата:
Сообщение: Re: [HACKERS] column labels now with obligatory 'as'