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 по дате отправления:

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: [HACKERS] CLUSTER command progress monitor
Следующее
От: Masahiko Sawada
Дата:
Сообщение: Re: Failed to delete old ReorderBuffer spilled files