From: | Mario Weilguni <mweilguni(at)sime(dot)com> |
---|---|
To: | Ow Mun Heng <Ow(dot)Mun(dot)Heng(at)wdc(dot)com> |
Cc: | Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Pgsql performance <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: Altering a column type - Most efficient way |
Date: | 2008-07-11 08:01:08 |
Message-ID: | 48771344.3020305@sime.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Ow Mun Heng schrieb:
> On Thu, 2008-07-10 at 09:57 -0400, Alvaro Herrera wrote:
>
>> Ow Mun Heng wrote:
>>
>>
>>> This is what I see on the table
>>>
>>> NEW attypmod = -1
>>> OLD attypmod = 8
>>>
>> 8 means varchar(4) which is what you said you had (4+4)
>> -1 means unlimited size.
>>
>>
>
> This is cool.
>
> If it were this simple a change, I'm not certain why (I believe) PG is
> checking each and every row to see if it will fit into the new column
> definition/type.
>
> Thus, I'm still a bit hesitant to do the change, although it is
> definitely a very enticing thing to do. ( I presume also that this
> change will be instantaneous and does not need to check on each and
> every row of the table?)
>
> Thanks./
>
>
It should be safe, because the length limit is checked at insert/update
time, and internally, a varchar(20) is treated as something like this:
foo varchar(1000000000) check (length(foo) <= 20)
The change is done without re-checking all rows, and will not fail IF
the new size is longer than the old size.
From | Date | Subject | |
---|---|---|---|
Next Message | Jeff | 2008-07-11 13:26:37 | 3ware vs Areca |
Previous Message | Ramasubramanian | 2008-07-11 07:35:47 | Trigger is taking time to fire |