Re: Doubt in pgbench TPS number - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Doubt in pgbench TPS number
Date
Msg-id 20076.1443450058@sss.pgh.pa.us
Whole thread Raw
In response to Re: Doubt in pgbench TPS number  (Fabien COELHO <coelho@cri.ensmp.fr>)
Responses Re: Doubt in pgbench TPS number  (Fabien COELHO <coelho@cri.ensmp.fr>)
Re: Doubt in pgbench TPS number  (Tatsuo Ishii <ishii@postgresql.org>)
List 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 by date:

Previous
From: Marti Raudsepp
Date:
Subject: [PATCH] Skip ALTER x SET SCHEMA if the schema didn't change
Next
From: "Shulgin, Oleksandr"
Date:
Subject: Re: On-demand running query plans using auto_explain and signals