Dimitri Fontaine <dfontaine@hi-media.com> writes:
> Robert Haas <robertmhaas@gmail.com> writes:
>> What you just said is about what I had in mind. I admit I can't
>> articulate a more detailed design right off the top of my head, but
>> the architecture you're proposing seems dead certain to never cover
>> more than 0.1% of what people actually do.
> Well, considering what we have now, the proposal is solid enough for
> me. As far as supporting VACUUM or REINDEX operations, my feeling is
> that offering a way to report current block being worked on and being
> able to see that move is enough a progress indication.
I don't really think that that would satisfy anybody. If you want to be
reassured that VACUUM is doing something, you can look at iostat
numbers, or strace the process, or something like that. What people
expect from a progress indicator is to get some idea of how much longer
the operation is likely to take, and current block doesn't do it
(mainly because it doesn't account for index cleanup scans). REINDEX
is even worse: how do you estimate progress when there's a table scan,
then a sort, then the actual index build?
I'm with Robert on this. A facility that's limited to information we
can get "for free" (and btw, it isn't even for free, only for relatively
cheap) isn't going to get the job done. We should be looking for
something that expends extra cycles when the information is demanded,
and otherwise not.
regards, tom lane
