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
|
Список | 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 по дате отправления: