On Tue, 2011-01-11 at 08:06 -0500, Noah Misch wrote:
> On Tue, Jan 11, 2011 at 12:37:28PM +0000, Simon Riggs wrote:
> > On Tue, 2011-01-11 at 07:14 -0500, Noah Misch wrote:
> >
> > > These changes do make it harder to guess how much work the ALTER TABLE
> > > will do. Indeed, about 1/4 of my own guesses prior to writing were
> > > wrong. Something like WITHOUT REWRITE might be the way to go, though
> > > there are more questions: if it does not rewrite, does it scan the
> > > table? Which indexes, if any, does it rebuild? Which foreign key
> > > constraints, if any, does it recheck? With patch 0, you can answer
> > > all these questions by enabling DEBUG1 messages and trying the command
> > > on your test system. For this reason, I did consider adding a VERBOSE
> > > clause to show those messages at DETAIL, rather than unconditionally
> > > showing them at DEBUG1. In any case, if a WITHOUT REWRITE like you
> > > describe covers the important question, it's certainly easy enough to
> > > implement.
> >
> > Trouble is, only superusers can set DEBUG1.
>
> Setting client_min_messages in one's session works, as does "ALTER ROLE myself
> SET client_min_messages = debug1". Still, indeed, DEBUG1 is not the usual place
> to send a user for information.
>
> > You're right, its more complex than I made out, though that strengthens
> > the feeling that we need a way to check what it does before it does it,
> > or a way to limit your expectations. Ideally that would be a
> > programmatic way, so that pgAdmin et al can issue a warning.
> >
> > Given your thoughts above, my preference would be for
> > EXPLAIN ALTER TABLE to describe the actions that will take place.
>
> That does seem like the best UI. Offhand, I would guess that's a project larger
> than the patch series I have here. We'd need to restructure ALTER TABLE into
> clear planning and execution stages, if not use the actual planner and executor.
Please do something that works in this release, whatever that is. I will
follow your lead in putting a similar mechanism in for judging lock
levels.
I don't want to be looking through the docs each time I run this,
sweating between it taking 5 secs and 5 hours on a big server.
We need to be able to run stuff overnight, with certainty that we know
what will happen.
And I want a clear answer when the "but how can you be certain?"
question gets asked.
Thank you for the rest of the patch.
-- Simon Riggs http://www.2ndQuadrant.com/books/PostgreSQL Development, 24x7 Support, Training and Services
