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
Следующее
От: Kyotaro HORIGUCHI
Дата:
Сообщение: Asynchronous execution on FDW