Horton

Re: Big performance slowdown from 11.2 to 13.3

Alvaro Herrera <alvherre@alvh.no-ip.org>

View thread View on postgr.es
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>
Date: 2021-07-22T17:56:54Z
Lists: pgsql-performance 
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/

Commits

  1. Get rid of artificial restriction on hash table sizes on Windows.