Re: Progress indication prototype
От | Tom Lane |
---|---|
Тема | Re: Progress indication prototype |
Дата | |
Msg-id | 13072.1284826206@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Progress indication prototype (Dimitri Fontaine <dfontaine@hi-media.com>) |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: