Skip site navigation (1) Skip section navigation (2)

Re: Avoiding rewrite in ALTER TABLE ALTER TYPE

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Noah Misch <noah(at)leadboat(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Avoiding rewrite in ALTER TABLE ALTER TYPE
Date: 2010-12-29 19:01:28
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Dec 29, 2010, at 11:16 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> 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 it has potential in cases like text to xml.  In that case it'll either work or fail, with no possibility of requiring a do-over.  Scanning the whole table is a whole lot cheaper than rewriting it.

I don't believe avoiding the write part (but not the read part, nor the
XML syntax verification part) is a sufficiently compelling argument to
justify having that code path.  There are not enough distinct datatypes
sharing binary representations to make this a worthwhile thing to worry

Basically, I believe that the only use-case that will have more than
epsilon number of users is "I want to make this varchar(5) into
varchar(10), or possibly text".  We can fix that case without adding a
boatload more code that we'll have to maintain.

I do have some interest in the idea of having a type-specific function
that can recognize no-op typmod changes, but I would envision that as
being an expression evaluation optimization: let the planner throw away
the call to the length-checking function when it isn't going to do
anything.  It's not by any means only useful in ALTER COLUMN TYPE ---
and in fact probably doesn't even need any bespoke code there, if we put
it into expression_planner() instead.

			regards, tom lane

In response to


pgsql-hackers by date

Next:From: Alvaro HerreraDate: 2010-12-29 19:12:21
Subject: Re: Streaming replication as a separate permissions
Previous:From: Robert HaasDate: 2010-12-29 18:49:40
Subject: Re: Libpq PGRES_COPY_BOTH - version compatibility

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group