| From: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
|---|---|
| To: | "ldh(at)laurent-hasson(dot)com" <ldh(at)laurent-hasson(dot)com> |
| Cc: | Peter Geoghegan <pg(at)bowt(dot)ie>, Justin Pryzby <pryzby(at)telsasoft(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, David Rowley <dgrowleyml(at)gmail(dot)com>, "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org> |
| Subject: | Re: Big performance slowdown from 11.2 to 13.3 |
| Date: | 2021-07-22 17:56:54 |
| Message-ID: | 202107221756.opvnumaebyht@alvherre.pgsql |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
On 2021-Jul-22, ldh(at)laurent-hasson(dot)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/
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Vijaykumar Jain | 2021-07-22 20:31:45 | Re: Big performance slowdown from 11.2 to 13.3 |
| Previous Message | Ranier Vilela | 2021-07-22 17:56:03 | Re: Big performance slowdown from 11.2 to 13.3 |