On Tue, Jan 11, 2011 at 01:17:23PM +0000, Simon Riggs wrote:
> 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:
> > > 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.
Okay; I'll see what I can come up with. The other part I was going to try to
finish before the last commitfest begins is avoiding unnecessary rebuilds of
indexes involving changed columns. Is that more or less important than having
an EXPLAIN ALTER TABLE?
> 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.
Just to clarify: does Robert's suggestion of starting the command in a
transaction block and cancelling it after messages appear (on any other DB with
the same schema, if need be) give too little certainty? You could check
pg_locks to see what lock was taken, too. It's surely not the ideal user
experience, but it seems dependable at least.
Thanks,
nm
