Re: Re: [BUGS] BUG #4689: Expanding the length of a VARCHAR column should not induce a table rewrite

From: Xuân Baldauf <xuan--2009(dot)03--submitbug--support--postgresql(dot)org(at)baldauf(dot)org>
To: Jaime Casanova <jcasanov(at)systemguards(dot)com(dot)ec>
Cc: Matteo Beccati <php(at)beccati(dot)com>, Guillaume Smet <guillaume(dot)smet(at)gmail(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, pgsql-bugs(at)postgresql(dot)org, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Re: [BUGS] BUG #4689: Expanding the length of a VARCHAR column should not induce a table rewrite
Date: 2009-03-05 20:27:34
Message-ID: 49B035B6.2010204@baldauf.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-hackers

Jaime Casanova wrote:
> On Thu, Mar 5, 2009 at 10:47 AM, Matteo Beccati <php(at)beccati(dot)com> wrote:
>
>> Guillaume Smet ha scritto:
>>
>>> On Wed, Mar 4, 2009 at 11:50 AM, Peter Eisentraut <peter_e(at)gmx(dot)net> wrote:
>>>
>>>> The question is how you want to implement this in a data type independent
>>>> fashion. You can't assume that increasing the typmod is a noop for all data
>>>> types.
>>>>
>>> Sure. See my previous answer on -hackers (I don't think this
>>> discussion belong to -bugs) and especially the discussion in the
>>> archives about Jonas' patch.
>>>
>> I recently had a similar problem when I added some domains to the
>> application. ALTER TABLE ... TYPE varchar_dom was leading to a full
>> table rewrite even though the underlying type definition were exactly
>> the same (i.e. varchar(64)). I can live with it, but I suppose this fix
>> might be related to the varlen one.
>>
>>
>
> ALTER TABLE ... TYPE does cause a table rewrite even if new_type =
> old_type, and that is actually useful...
> for example when you add a fillfactor to an existing table that
> fillfactor will not affect the existing data until you rewrite the
> table and a convenient way is exactly using ALTER TABLE ... TYPE.
>
Well, while this behaviour is well-known for PostgreSQL, this is
actually an abuse of syntax. If there are legitimate requirements for
rewriting a table, then there should be explicit syntax for such a
feature, like "ALTER TABLE ... REWRITE". Rewriting a table in case of
"ALTER TABLE ... TYPE" is, by the semantics of that statement, just a
side-effect, which may or may not happen, depending on how optimized the
DBMS is. It is bad design to avoid optimization just because an
unnecessary side-effect would be optimized away.
> now, back to the problem... is not easier to define a column as TEXT
> and to put a check to constraint the length? if you wanna change the
> constraint that will be almost free
No. Is it possible to change the column type from VARCHAR(5) to TEXT
without a table-rewrite penalty?

ciao,
Xuân.

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Jaime Casanova 2009-03-05 20:37:22 Re: [HACKERS] Re: BUG #4689: Expanding the length of a VARCHAR column should not induce a table rewrite
Previous Message Kevin Grittner 2009-03-05 19:55:59 Re: Re: [BUGS] BUG #4689: Expanding the length of a VARCHAR column should not induce a table rewrite

Browse pgsql-hackers by date

  From Date Subject
Next Message Jaime Casanova 2009-03-05 20:37:22 Re: [HACKERS] Re: BUG #4689: Expanding the length of a VARCHAR column should not induce a table rewrite
Previous Message Dickson S. Guedes 2009-03-05 19:56:40 Re: cbrt() broken in AIX