Re: Avoiding rewrite in ALTER TABLE ALTER TYPE

From: Noah Misch <noah(at)leadboat(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Avoiding rewrite in ALTER TABLE ALTER TYPE
Date: 2010-12-29 23:52:42
Message-ID: 20101229235242.GC30520@tornado.gateway.2wire.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Dec 29, 2010 at 11:16:23AM -0500, Tom Lane wrote:
> Noah Misch <noah(at)leadboat(dot)com> writes:
> > ALTER TABLE ALTER TYPE always rewrites the table heap and its indexes. In some
> > cases, we can determine that doing so is unhelpful, and that the conversion
> > shall always succeed:
> > I wish to replace table rewrites with table verification scans where possible,
> > then skip those verification scans where possible.
>
> This has been discussed before; have you read the previous threads?

I cited two threads I had read on the subject. Were there other important ones?

> I really really dislike the notion of a "verification scan": it's
> basically work that is going to be useless if it fails. I think your
> argument that it will usually fail quickly is quite unconvincing, and in
> any case the situations where it is useful at all are too thin on the
> ground to be worth the code space to implement it. It seems sufficient
> to me to skip the rewrite in cases of provable binary compatibility, with
> possibly an extra check for "safe" changes of typmod. With respect to
> the latter, I agree a type-specific function to compare the typmods
> would be the way to go, although "exemptor" seems a pretty badly chosen
> name for it.

I have attempted to expand on these problems in my reply to Robert.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message KaiGai Kohei 2010-12-30 00:26:07 Re: sepgsql contrib module
Previous Message Josh Berkus 2010-12-29 23:47:56 Re: estimating # of distinct values