Re: Command statistics system (cmdstats)

From: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com>, Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org>, "Smith, Peter" <peters(at)fast(dot)au(dot)fujitsu(dot)com>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Dilip Kumar <dilipbalaut(at)gmail(dot)com>, vinayak <Pokale_Vinayak_q3(at)lab(dot)ntt(dot)co(dot)jp>
Subject: Re: Command statistics system (cmdstats)
Date: 2020-09-21 13:41:46
Message-ID: 20200921134146.GA20880@alvherre.pgsql
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On 2020-Sep-18, Michael Paquier wrote:

> Based on the low level of activity and the fact that the patch was
> marked as waiting on author for a couple of weeks, it looks like
> little could be achieved by the end of the CF, and the attention was
> elsewhere, so it looked better (and it still does IMO) to give more
> attention to the remaining 170~ patches that are still lying on the CF
> app.

"A couple of weeks" of inactivity is not sufficient, in my view, to boot
a patch out of the commitfest process. Whenever the patch is
resurrected, it will be a new entry which won't have the history that it
had accumulated in the long time since it was created -- which biases
it against other new patches.

I'm not really arguing about this one patch only, but more generally
about the process you're following. The problem is that you as CFM are
imposing your personal priorities on the whole process by punting
patches ahead of time -- you are saying that nobody else should be
looking at updating this patch because it is now closed. It seems fair
to do so at the end of the commitfest, but it does not seem fair to do
it when it's still mid-cycle.

Putting also in perspective the history that the patch had prior to your
unfairly closing it, there was a lot of effort in getting it reviewed to
a good state and updated by the author -- yet a single unsubstantiated
comment, without itself a lot of effort on the reviewer's part, that
"maybe it has a perf drawback" is sufficient to get it booted? It
doesn't seem appropriate.

Álvaro Herrera
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Andrey M. Borodin 2020-09-21 14:19:32 Re: Yet another fast GiST build
Previous Message Matthieu Garrigues 2020-09-21 13:41:13 Re: PATCH: Batch/pipelining support for libpq