Re: NUMERIC x VARCHAR

Поиск
Список
Период
Сортировка
От Jan Wieck
Тема Re: NUMERIC x VARCHAR
Дата
Msg-id 411A715C.70808@Yahoo.com
обсуждение исходный текст
Ответ на Re: NUMERIC x VARCHAR  ("Scott Marlowe" <smarlowe@qwest.net>)
Список pgsql-performance
On 8/11/2004 2:21 AM, Scott Marlowe wrote:

> On Tue, 2004-08-10 at 23:42, Er Galvão Abbott wrote:
>> Greetings.
>>
>> I have a question regarding performance of certain datatypes:
>>
>> I have a field where I will store my clients phone numbers. I know
>> that this field will never exceed 15 characters, and I will store only
>> numbers here (no dashes, dots, etc...), so I was wondering:
>>
>> Wich type is faster: NUMERIC(15,0) or VARCHAR(15)? Are there any
>> storage differences between them?
>
> Since numerics are stored as text strings, the storage would be
> similar.  Numerics, however, may be slower since they have more
> constraints built in.  If you throw a check constraint on the
> varchar(15) then it will likely be about the same speed for updating.

They are stored as an array of signed small integers holding digits in
base-10000, plus a precision, scale and sign. That's somewhat different
from text strings, isn't it?


Jan

>
> text type with a check contraint it what i'd use.  That way if you want
> to change it at a later date you just drop and recreate your constraint.
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
>
>                http://www.postgresql.org/docs/faqs/FAQ.html


--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck@Yahoo.com #

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

Предыдущее
От: "Jason Coene"
Дата:
Сообщение: Re: Hardware upgrade for a high-traffic database
Следующее
От: Brian Hirt
Дата:
Сообщение: Re: Hardware upgrade for a high-traffic database