Re: [HACKERS] CLUSTER command progress monitor
От | Thomas Munro |
---|---|
Тема | Re: [HACKERS] CLUSTER command progress monitor |
Дата | |
Msg-id | CAEepm=2Ow9pXbKi_+SjwVTkCZH3UkN4o7KMq3feWz2CmoZ4jQg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] CLUSTER command progress monitor (Michael Paquier <michael.paquier@gmail.com>) |
Список | pgsql-hackers |
On Wed, Nov 22, 2017 at 1:53 PM, Michael Paquier <michael.paquier@gmail.com> wrote: > On Wed, Nov 22, 2017 at 5:55 AM, Robert Haas <robertmhaas@gmail.com> wrote: >> I have been of the opinion all along that progress monitoring needs to >> report facts, not theories. The number of tuples read thus far is a >> fact, and is fine to report for whatever value it may have to someone. >> The number of tuples that will be read in the future is a theory, and >> as you say, progress monitoring is most likely to be used in cases >> where theory and practice ended up being very different. > > +1. We should never as well enter in things like trying to estimate > the amount of time remaining to finish a task [1]. > > [1]: https://www.xkcd.com/612/ +1 That is one reason I made pg_stat_replication.XXX_lag report the lag of WAL that has been processed, not (say) the time until we catch up. In some information-poor scenarios it interpolates which isn't perfect but the general idea is that is shows you measurements of the past (facts), not predictions about the future (theories). -- Thomas Munro http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: