Re: ALTER TYPE 3: add facility to identify further no-work cases - Mailing list pgsql-hackers

From Tom Lane
Subject Re: ALTER TYPE 3: add facility to identify further no-work cases
Date
Msg-id 9482.1296089083@sss.pgh.pa.us
Whole thread Raw
In response to Re: ALTER TYPE 3: add facility to identify further no-work cases  (Noah Misch <noah@leadboat.com>)
Responses Re: ALTER TYPE 3: add facility to identify further no-work cases  (Robert Haas <robertmhaas@gmail.com>)
Re: ALTER TYPE 3: add facility to identify further no-work cases  (Noah Misch <noah@leadboat.com>)
List pgsql-hackers
Noah Misch <noah@leadboat.com> writes:
> On Wed, Jan 26, 2011 at 06:29:57PM -0500, Tom Lane wrote:
>> I remain completely unexcited about optimizing that case, especially if
>> it doesn't fit into a general framework.  The bang for the buck ratio
>> is not good: too much work, too much uglification, too little return.

> The return looks attractive when you actually save six hours of downtime.  If
> I'm the only one that sees such a savings for one of his databases, though, I
> suppose it's not worthwhile.  We'd miss optimizing these cases:

> numeric(8,2) -> numeric(7,2)
> varbit(8) -> varbit(7)
> text -> xml

But how often do those really come up?  And do you really save that
much?  The table still has to be locked against other users, so you're
still down, and you're still doing all the reads and computation.  I
don't deny that saving the writes is worth something; I just don't agree
that it's worth the development and maintenance effort that such a wart
is going to cost us.  User-exposed features are *expensive*.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Noah Misch
Date:
Subject: Re: ALTER TYPE 3: add facility to identify further no-work cases
Next
From: "Joshua D. Drake"
Date:
Subject: Re: [RRR] Seeking Mentors for Funded Reviewers