On 4 December 2012 22:30, Tom Lane <t...@sss.pgh.pa.us> wrote: > Josh Berkus <j...@agliodbs.com> writes: >>>> However, for a very large user group -- users with ORMs which do their >>>> own DDL migrations -- we could also use a way to log or WARN for table >>>> rewrites. Since the ORMs are not gonna do an EXPLAIN. > >>> An ORM is also quite unlikely to pay attention to a warning, much less a >>> postmaster log entry ... so your argument seems unfounded from here. > >> But the DevOps staff *is*. > > Sure, and the DevOps staff would be using the EXPLAIN feature (if we had > it). After which they could do little anyway except complain to the ORM > authors, who might or might not give a damn. I don't see that there's > enough value-added from what you suggest to justify the development > time.
I've never had my POLA violated, so its hard to comment on so many buzzphrases. But normal people I've worked with do struggle with knowing for certain what will happen when they run a DDL change script on a production system, which is the heart of the problem. Other software lags behind the services we provide, but if we never provide it they definitely will never use it. Eyeballs work well, but something automated else would work even better. Adding EXPLAIN in front of everything doesn't work at all because many actions depend upon the results of earlier actions, so the test must actually perform the action in order for the whole script to work. Plus, if we have to edit a script to add EXPLAIN in front of everything, you can't put it live without editing out the EXPLAINs, which leaves you open to the failure caused by editing immediately prior to go live. So my NOREWRITE option fails those criteria and should be discarded. On reflection, what is needed is a way to ask "what just happened" when a script is tested. The best way to do that is a special stats collection mode that can be enabled just for that run and then the stats analyzed afterwards. Noah's contribution comes closest to what we need, but its not complete enough, yet. I'll have a play with this idea some more. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
