Re: How to find greatest record before known values fast
От | Adrian Klaver |
---|---|
Тема | Re: How to find greatest record before known values fast |
Дата | |
Msg-id | 542F2502.7010302@aklaver.com обсуждение исходный текст |
Ответ на | Re: How to find greatest record before known values fast ("Andrus" <kobruleht2@hot.ee>) |
Ответы |
Re: How to find greatest record before known values fast
|
Список | pgsql-general |
On 10/03/2014 01:28 PM, Andrus wrote: > Hi! > > Thank you for explanations. > >> the char type pads out the fields on disk. > > It looks like you wrote that char takes more disk space. > > from > > http://www.pgcon.org/2013/schedule/attachments/269_tour-of-postgresql-data-types.pdf > > > page 28: > > Unlike many > databases, char(n) is NOT stored as afixed-sizedfield > in Postgres. It is treated exactly the sameas > varchar(n)except for being padded > > So char type does not take more space than varchar. Which directly contradicts the information on page 27: Character Types (or Strings) Name Description varchar(n) variable-length with limit char(n) fixed-length, blank padded text variable unlimited length and the docs: http://www.postgresql.org/docs/9.3/interactive/datatype-character.html Values of type character are physically padded with spaces to the specified width n, and are stored and displayed that way. However, the padding spaces are treated as semantically insignificant. Trailing spaces are disregarded when comparing two values of type character, and they will be removed when converting a character value to one of the other string types. Note that trailing spaces are semantically significant in character varying and text values, and when using pattern matching, e.g. LIKE, regular expressions. Tip: There is no performance difference among these three types, apart from increased storage space when using the blank-padded type, and a few extra CPU cycles to check the length when storing into a length-constrained column. While character(n) has performance advantages in some other database systems, there is no such advantage in PostgreSQL; in fact character(n) is usually the slowest of the three because of its additional storage costs. In most situations text or character varying should be used instead. > > Andrus. > > -- Adrian Klaver adrian.klaver@aklaver.com
В списке pgsql-general по дате отправления: