Re: Function transform optimizations versus reality

On Wed, Jan 18, 2017 at 12:10 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> More generally, this is the second serious bug we've found in the last
> month in the "transform" optimizations (see also bug #14479 and commit
> f0774abde). I'm starting to get the feeling that that idea was an
> attractive nuisance --- at the very least, it would behoove us to go
> through all the transform functions with a gimlet eye.

So, two things for perspective:

1. Transform functions have been around for just over 5 years now; if
the two bugs we have had in the last month are the only ones, that's a
better track record than most features. If we've had one a month for
5 years, that's terrible, of course, but I don't think that's so.

2. The value of these transform functions is principally in that table
rewrites can be avoided when executing ALTER TABLE. And that is a big
value. People are still looking for ways to further reduce table
rewrites, as evidenced for example by Serge Rielau's patch for
implicit defaults.

Of course, it is entirely possible that Noah and I missed some
important things when we added that feature, and an audit of the code
is very welcome. But I would discourage you from disabling any more
of the optimization than necessary, because I think people really care
about whether ALTER TABLE has to rewrite the table or just lock it
long enough to change the metadata.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company