Обсуждение: BUG #4689: Expanding the length of a VARCHAR column should not induce a table rewrite

Поиск
Список
Период
Сортировка
The following bug has been logged online:

Bug reference:      4689
Logged by:
Email address:
xuan--2009.03--submitbug--support--postgresql.org@baldauf.org
PostgreSQL version: 8.3.5
Operating system:   Linux 2.6.18-6-amd64
Description:        Expanding the length of a VARCHAR column should not
induce a table rewrite
Details:

Suppose there is a table "sometable" with a column "somecolumn" of type
"VARCHAR(5)".

This table as many rows.

When executing
"ALTER TABLE sometable ALTER COLUMN somecolumn TYPE VARCHAR(7)", the whole
table is re-written, and this rewrite takes many hours. During these hours,
all writers on this table stall, making the database effectively
unavailable.

However, in almost all cases, there is no need for such relaxing of limits
to require a table rewrite.

So the expected run time needed for this statement is about one second, the
actual run time needed for this statement is many hours.

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

От
Heikki Linnakangas
Дата:
xuan--2009.03--submitbug--support--postgresql.org@baldauf.org wrote:
> When executing
> "ALTER TABLE sometable ALTER COLUMN somecolumn TYPE VARCHAR(7)", the whole
> table is re-written, and this rewrite takes many hours. During these hours,
> all writers on this table stall, making the database effectively
> unavailable.
>
> However, in almost all cases, there is no need for such relaxing of limits
> to require a table rewrite.

While this isn't a bug, it's a reasonable feature request. I've added
this to the TODO page: http://wiki.postgresql.org/wiki/Todo#ALTER

Patches are welcome.

--
   Heikki Linnakangas
   EnterpriseDB   http://www.enterprisedb.com

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

От
Peter Eisentraut
Дата:
Heikki Linnakangas wrote:
> xuan--2009.03--submitbug--support--postgresql.org@baldauf.org wrote:
>> When executing
>> "ALTER TABLE sometable ALTER COLUMN somecolumn TYPE VARCHAR(7)", the
>> whole
>> table is re-written, and this rewrite takes many hours. During these
>> hours,
>> all writers on this table stall, making the database effectively
>> unavailable.
>>
>> However, in almost all cases, there is no need for such relaxing of
>> limits
>> to require a table rewrite.
>
> While this isn't a bug, it's a reasonable feature request. I've added
> this to the TODO page: http://wiki.postgresql.org/wiki/Todo#ALTER
>
> Patches are welcome.

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.

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

От
Guillaume Smet
Дата:
On Wed, Mar 4, 2009 at 11:50 AM, Peter Eisentraut <peter_e@gmx.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.

--
Guillaume


Guillaume Smet ha scritto:
> On Wed, Mar 4, 2009 at 11:50 AM, Peter Eisentraut <peter_e@gmx.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.


Cheers

-- 
Matteo Beccati

OpenX - http://www.openx.org


On Thu, Mar 5, 2009 at 10:47 AM, Matteo Beccati <php@beccati.com> wrote:
> Guillaume Smet ha scritto:
>> On Wed, Mar 4, 2009 at 11:50 AM, Peter Eisentraut <peter_e@gmx.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.

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

--
Atentamente,
Jaime Casanova
Soporte y capacitación de PostgreSQL
Asesoría y desarrollo de sistemas
Guayaquil - Ecuador
Cel. +59387171157


On Thu, Mar 5, 2009 at 3:27 PM, Xuân Baldauf
<xuan--2009.03--submitbug--support--postgresql.org@baldauf.org> wrote:
>
>
> 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.
>

note that this is my opinion and not represent the PGDG (Postgresql
Global Development Group) opinion

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

the idea is to make that change once (and to create new tables just with TEXT)

and then you can make ALTER TABLE ... ADD CHECK (length(column) =
a_value) as many times as you want without the need for a table
rewrite

--
Atentamente,
Jaime Casanova
Soporte y capacitación de PostgreSQL
Asesoría y desarrollo de sistemas
Guayaquil - Ecuador
Cel. +59387171157