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
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 |
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 |