Re: Suggested TODO: allow ALTERing of typemods without heap/index rebuild - Mailing list pgsql-hackers

From Dimitri Fontaine
Subject Re: Suggested TODO: allow ALTERing of typemods without heap/index rebuild
Date
Msg-id 87prdn2fqv.fsf@hi-media-techno.com
Whole thread Raw
In response to Re: Suggested TODO: allow ALTERing of typemods without heap/index rebuild  (Josh Berkus <josh@agliodbs.com>)
List pgsql-hackers
Hi,

Josh Berkus <josh@agliodbs.com> writes:
>> The stumbling block has been to identify a reasonably clean way
>> of determining which datatype changes don't require a scan.
>
> Yep.  One possibility I'm thinking is supplying a function for each type
> which takes two typemods (old and new) and returns a value (none, check,
> rebuild) which defines what we need to do: nothing, check but not rebuild,
> or rebuild.  Default would be rebuild.  Then the logic is simple for each
> data type.

That seems like a good idea, I don't see how the current infrastructure
could provide enough information to skip this here. Add in there whether
a reindex is needed, too, in the accepted return values (maybe a mask is
needed, such as NOREWRITE|REINDEX).

> Note that this doesn't deal with the special case of VARCHAR-->TEXT, but
> just with changing typemods.  Are there other cases of data *type*
> conversions where no check or rebuild is required?  Otherwise we might just
> special case VARCHAR-->TEXT.

It seems there's some new stuff for this in 8.4, around the notions of
binary coercibility and type categories, which allow user defined types
to be declared IO compatible with built-in types, e.g. citext/text.

Maybe the case is not so special anymore?
 http://git.postgresql.org/gitweb?p=postgresql.git;a=commit;h=22ff6d46991447bffaff343f4e333dcee188094d
http://git.postgresql.org/gitweb?p=postgresql.git;a=commit;h=4a3be7e52d7e87d2c05ecc59bc4e7d20f0bc9b17

> Oh, here's a general case: changing DOMAINs on the same base type should
> only be a check, and changing from a DOMAIN to its own base type should be a
> none.

DOMAINs and CASTs are still on the todo list IIRC, so I'm not sure the
current infrastructure around DOMAINs would be flexible (or complete)
enough for the system to determine when the domain A to domain B type
change is binary coercible. It has no CAST information to begin with, I
guess.

As far as reindexing is concerned, talking with RhodiumToad (Andrew
Gierth) on IRC gave insights, as usual. Standard PostgreSQL supports two
data type change without reindex needs: varchar to text and cidr to
inet. In both cases, the types share the indexing infrastructure: same
PROCEDUREs are in use in the OPERATORs that the index is using.

Could it be that we already have the information we need in order to
dynamically decide whether a heap rewrite and a reindex are necessary,
even in case of user defined type conversions?

Regards,
-- 
dim


pgsql-hackers by date:

Previous
From: "Markus Wanner"
Date:
Subject: Re: User-facing aspects of serializable transactions
Next
From: "Markus Wanner"
Date:
Subject: Re: PostgreSQL Developer meeting minutes up