Re: Altering a column type - Most efficient way

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: "Alvaro Herrera" <alvherre(at)commandprompt(dot)com>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Pgsql performance" <pgsql-performance(at)postgresql(dot)org>, "Mario Weilguni" <mweilguni(at)sime(dot)com>, "Ow Mun Heng" <Ow(dot)Mun(dot)Heng(at)wdc(dot)com>
Subject: Re: Altering a column type - Most efficient way
Date: 2008-07-11 14:55:06
Message-ID: 48772E39.EE98.0025.0@wicourts.gov
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

>>> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
>> Ow Mun Heng wrote:
>>> 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.
>
>> Because the code that does the ALTER TYPE is very generic, and it
>> doesn't (yet) have an optimization that tells it to skip the check
and
>> the possible table rewrite in the cases where it's obviously not
needed
>> (like this one).
>
> Awhile back I looked into teaching ALTER TYPE that it needn't
rewrite
> if the type conversion expression parses out as just a Var with
> RelabelType, but it seemed that that wouldn't cover very much of the
> use-cases where a human thinks that it's "obvious" that no rewrite
> is needed.

We wouldn't have to cover all possible cases for it to be useful. If
there's some low-hanging fruit here, +1 for getting that. The cases
which would most often save staff here some time are switching a
varchar to a longer maximum length or switching between a domain which
is varchar to plain varchar (or vice versa).

-Kevin

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Luke Lonergan 2008-07-11 14:59:00 Re: 3ware vs Areca
Previous Message Tom Lane 2008-07-11 14:27:34 Re: Altering a column type - Most efficient way