Re: Expanding the length of a VARCHAR column should not induce a table rewrite

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: "Matteo Beccati" <php(at)beccati(dot)com>, "Guillaume Smet" <guillaume(dot)smet(at)gmail(dot)com>
Cc: "Heikki Linnakangas" <heikki(dot)linnakangas(at)enterprisedb(dot)com>, "Peter Eisentraut" <peter_e(at)gmx(dot)net>, "pgsql-hackers" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Expanding the length of a VARCHAR column should not induce a table rewrite
Date: 2009-03-05 19:15:26
Message-ID: 49AFD06D.EE98.0025.0@wicourts.gov
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-hackers

Took bugs list off, as this is clearly not a bug.

>>> Matteo Beccati <php(at)beccati(dot)com> wrote:
> 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.

Been there. We also occasionally increase the length of a
verchar-based domain. The process could be made faster and more
convenient by avoiding rewrites when possible. On particularly large
tables I've sometimes ventured into direct updates to the system
tables for these.

-Kevin

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Jaime Casanova 2009-03-05 19:26:51 Re: [HACKERS] Re: BUG #4689: Expanding the length of a VARCHAR column should not induce a table rewrite
Previous Message Matteo Beccati 2009-03-05 15:47:30 Re: [HACKERS] Re: 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 Peter Eisentraut 2009-03-05 19:16:19 Re: Make SIGHUP less painful if pg_hba.conf is not readable
Previous Message Tom Lane 2009-03-05 19:10:36 Re: Operators based on non-IMMUTABLE functions