Re: Doubt in pgbench TPS number

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Doubt in pgbench TPS number
Дата
Msg-id 20076.1443450058@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Doubt in pgbench TPS number  (Fabien COELHO <coelho@cri.ensmp.fr>)
Ответы Re: Doubt in pgbench TPS number  (Fabien COELHO <coelho@cri.ensmp.fr>)
Re: Doubt in pgbench TPS number  (Tatsuo Ishii <ishii@postgresql.org>)
Список pgsql-hackers
Fabien COELHO <coelho@cri.ensmp.fr> writes:
>> Yeah, that's definitely a bug but I'm afraid the fix will change the
>> TPS number and may break the backward compatibility. Since we have
>> lived with bug for years, I hesitate to back port to older stable
>> branches...

> My 2�: I do not think of a good argument to keep wrong tps numbers once it 
> is known that there are plain wrong, especially as it is not a behavioral 
> change as such which could block applications or whatever, just a 
> different number printed at the end of a run. So I would not bother much 
> with upward compatibility consideration in this case.

FWIW, I vote with Tatsuo-san.  Such a change will break comparability of
results with all previous versions, which means it's not something to do
in minor releases, even if we now believe the previous results were
somewhat bogus.  Arguing that it's "not a behavioral change" seems
quite loony to me: for most people, the TPS numbers are the only
interesting output of pgbench.

I think we should fix it in 9.5 and document it as an incompatible change.

(Note: I've not read the patch, so this is not an opinion about its
correctness.)
        regards, tom lane



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Marti Raudsepp
Дата:
Сообщение: [PATCH] Skip ALTER x SET SCHEMA if the schema didn't change
Следующее
От: "Shulgin, Oleksandr"
Дата:
Сообщение: Re: On-demand running query plans using auto_explain and signals