On Fri, Dec 11, 2015 at 1:25 AM, Michael Paquier <michael.paqu...@gmail.com> wrote: >> For another thing, there are definitely going to be >> some people that want the detailed information - and I can practically >> guarantee that if we don't make it available, at least one person will >> write a tool that tries to reverse-engineer the detailed progress >> information from whatever we do report. > > OK, so this justifies the fact of having detailed information, but > does it justify the fact of having precise and accurate data? ISTM > that having detailed information and precise information are two > different things. The level of details is defined depending on how > verbose we want the information to be, and the list you are giving > would fulfill this requirement nicely for VACUUM. The level of > precision/accuracy at which this information is provided though > depends at which frequency we want to send this information. For > long-running VACUUM it does not seem necessary to update the fields of > the progress tracker each time a counter needs to be incremented. > CLUSTER has been mentioned as well as a potential target for the > progress facility, but it seems that it enters as well in the category > of things that would need to be reported on a slower frequency pace > than "each-time-a-counter-is-incremented". > > My impression is just based on the needs of VACUUM and CLUSTER. > Perhaps I am lacking imagination regarding the potential use cases of > the progress facility though in cases where we'd want to provide > extremely precise progress information :) > It just seems to me that this is not a requirement for VACUUM or > CLUSTER. That's all.
It's not a hard requirement, but it should be quite easy to do without adding any significant overhead. All you need to do is something like: foo->changecount++; pg_write_barrier(); foo->count_of_blocks++; pg_write_barrier(); foo->changecount++; I suspect that's plenty cheap enough to do for every block. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
