From: | Dimitri Fontaine <dfontaine(at)hi-media(dot)com> |
---|---|
To: | Josh Berkus <josh(at)agliodbs(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Suggested TODO: allow ALTERing of typemods without heap/index rebuild |
Date: | 2009-06-02 08:37:28 |
Message-ID: | 87prdn2fqv.fsf@hi-media-techno.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
Josh Berkus <josh(at)agliodbs(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Markus Wanner | 2009-06-02 11:08:14 | Re: PostgreSQL Developer meeting minutes up |
Previous Message | Markus Wanner | 2009-06-02 07:17:00 | Re: User-facing aspects of serializable transactions |