Re: [PROPOSAL] VACUUM Progress Checker.
От | Guillaume Lelarge |
---|---|
Тема | Re: [PROPOSAL] VACUUM Progress Checker. |
Дата | |
Msg-id | CAECtzeUg5MibXeqAfqnb15i36WDo0b1bXi=0NCRp7wNahW+9xQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [PROPOSAL] VACUUM Progress Checker. (Simon Riggs <simon@2ndQuadrant.com>) |
Список | pgsql-hackers |
<p dir="ltr">Le 2 juil. 2015 7:28 AM, "Simon Riggs" <<a href="mailto:simon@2ndquadrant.com">simon@2ndquadrant.com</a>>a écrit :<br /> ><br /> > On 2 July 2015 at 03:00,Rahila Syed <<a href="mailto:rahilasyed90@gmail.com">rahilasyed90@gmail.com</a>> wrote:<br /> > <br /> >><br/> >> >Yes, I suggest just a single column on pg_stat_activity called pct_complete<br /> >><br/> >> Reporting remaining time also can be crucial to make decisions regarding continuing or aborting VACUUM. <br/> >> The same has been suggested in the thread below,<br /> >><br /> >> <a href="http://www.postgresql.org/message-id/13072.1284826206@sss.pgh.pa.us">http://www.postgresql.org/message-id/13072.1284826206@sss.pgh.pa.us</a><br />>><br /> >> >trace_completion_interval = 5s (default)<br /> >><br /> >> >Every interval,we report the current % complete for any operation that supports it. We just show NULL if the current operationhas not reported anything or never will.<br /> >><br /> >> >We do this for VACUUM first, then wecan begin adding other operations as we work out how (for that operation).<br /> >><br /> >> Thank you forexplaining. This design seems good to me except, adding more than one columns(percent_complete, remaining_time)<br />><br /> ><br /> > It is attractive to have a "remaining_time" column, or a "predicted_completion_timestamp", butthose columns are prediction calculations rather than actual progress reports. I'm interested in seeing a report thatrelates to actual progress made.<br /> ><p dir="ltr">Agreed.<p dir="ltr">> Predicted total work required is alsointeresting, but is much less trustworthy figure.<br /> ><p dir="ltr">And it is something a client app or an extensioncan compute. No need to put this in core as long as we have the actual progress.<p dir="ltr">> I think we'llneed to get wider input about the user interface for this feature.<br /> ><br /> > <br /> >><br /> >>if required to pg_stat_activity can be less user intuitive than having a separate view for VACUUM. <br /> ><br/> ><br /> > I think it is a mistake to do something just for VACUUM. <br /> ><br /> > Monitoring softwarewill look at pg_stat_activity. I don't think we should invent a separate view for progress statistics because itwill cause users to look in two places rather than just one. Reporting progress is fairly cheap instrumentation, calculatinga prediction of completion time might be expensive.<br /> ><p dir="ltr">+1<p dir="ltr">> Having said that,monitoring systems currently use a polling mechanism to retrieve status data. They look at information published bythe backend. We don't currently have a mechanism to defer publication of expensive monitoring information until requestedby the monitoring system. If you have a design for how that might work then say so, otherwise we need to assumea simple workflow: the backend publishes whatever it chooses, whenever it chooses and then that is made available viathe monitoring system via views.<br /> ><br /> ><br /> > Your current design completely misses the time takento scan indexes, which is significant.<br /> ><br /> > There might be a justification to put this out of core,but measuring progress of VACUUM wouldn't be it, IMHO.<br /> ><br /> > -- <br /> > Simon Riggs <a href="http://www.2ndQuadrant.com/">http://www.2ndQuadrant.com/</a><br /> > PostgreSQL Development, 24x7 Support,Remote DBA, Training & Services<br />
В списке pgsql-hackers по дате отправления:
Предыдущее
От: Michael PaquierДата:
Сообщение: Re: Support for N synchronous standby servers - take 2