Re: extra spaces
От | Tom Lane |
---|---|
Тема | Re: extra spaces |
Дата | |
Msg-id | 4571.977294837@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: extra spaces (Alvaro Herrera <alvherre@protecne.cl>) |
Список | pgsql-general |
Alvaro Herrera <alvherre@protecne.cl> writes: > According to "Postgres: Introduction and Concepts", varchar is slower > than char. So if you (like me) want to use char and get rid of the > padding spaces, you may use a regex replacement, as in > while (@row=$result->fetchrow) > { > $row[0] =~ s/[\s]+$//; > } I can confidently assure you that the performance differential between char and varchar is small enough to be swamped out by invocation of functions like the above. (Besides, it's gone entirely for PG 7.1.) And that's just based on pure CPU-time considerations, without regard for disk-transfer-time and cache-space-wastage issues. Padding spaces can easily cost you FAR more along those dimensions than you can ever hope to save from having a fixed tuple layout. IMHO, 'char(n)' is suitable for extremely small values of n where you *know* that space-padding is not the normal case. Almost the only natural example I can think of is two-letter USA postal abbreviations for states (such as PA in my address). Otherwise use 'varchar(n)' if your application has a natural upper bound on sensible string lengths, or 'text' if you can't instantly pick a specific value of the upper limit 'n'. regards, tom lane
В списке pgsql-general по дате отправления: