Date: Thu, 22 Jul 2021 13:56:54 -0400
From: Alvaro Herrera <alvherre@alvh.no-ip.org>
To: "ldh@laurent-hasson.com" <ldh@laurent-hasson.com>
Cc: Peter Geoghegan <pg@bowt.ie>, Justin Pryzby <pryzby@telsasoft.com>,
	Tom Lane <tgl@sss.pgh.pa.us>, David Rowley <dgrowleyml@gmail.com>,
	"pgsql-performance@postgresql.org" <pgsql-performance@postgresql.org>
Subject: Re: Big performance slowdown from 11.2 to 13.3
Message-ID: <202107221756.opvnumaebyht@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 
 <MN2PR15MB2560A2F486FE1ACB520ECCBD85E49@MN2PR15MB2560.namprd15.prod.outlook.com>
Archived-At: 
 <https://www.postgresql.org/message-id/202107221756.opvnumaebyht%40alvherre.pgsql>
Precedence: bulk

On 2021-Jul-22, ldh@laurent-hasson.com wrote:

> Yes, agreed Peter... The "lower priority" issue was mentioned, but not
> in terms of the applicability of the fix overall. Personally, I would
> prefer going the size_t route vs int/long/int64 in C/C++/. Of course,
> as a user, I'd love a patch on V13 and something cleaner in V14.

Just to clarify our terminology here.  "A patch" means any kind of
change to the source code, regardless of its cleanliness or
applicability to versions deemed stable.  You can have one patch which
is a ugly hack for a stable version that can't have invasive changes,
and another patch which is a clean, more maintainable version of a
totally different fix for the version in development.  We use the same
word, "patch", for both types of source code changes.

-- 
Álvaro Herrera         PostgreSQL Developer  —  https://www.EnterpriseDB.com/