From: Tom Lane <tgl@sss.pgh.pa.us>
To: "ldh@laurent-hasson.com" <ldh@laurent-hasson.com>
cc: Ranier Vilela <ranier.vf@gmail.com>, Andrew Dunstan <andrew@dunslane.net>,
        Justin Pryzby <pryzby@telsasoft.com>,
        "pgsql-performance@postgresql.org" <pgsql-performance@postgresql.org>
Subject: Re: Big Performance drop of Exceptions in UDFs between V11.2 and 13.4
In-reply-to: 
 <MN2PR15MB25605C2D5D70A6EAF99B5F6085CA9@MN2PR15MB2560.namprd15.prod.outlook.com>
References: 
 <MN2PR15MB2560AE2A878FBBE88DCFF33385C29@MN2PR15MB2560.namprd15.prod.outlook.com>
 <2092859.1629558281@sss.pgh.pa.us>
 <MN2PR15MB25607BDC72A325CA9B9D3E3385C29@MN2PR15MB2560.namprd15.prod.outlook.com>
 <2136207.1629569846@sss.pgh.pa.us> <20210821191950.GW10479@telsasoft.com>
 <MN2PR15MB2560ED2A8F967B14E7D7881E85C29@MN2PR15MB2560.namprd15.prod.outlook.com>
 <20210821221729.GY10479@telsasoft.com>
 <MN2PR15MB2560FB03666CEABB651FB32185C29@MN2PR15MB2560.namprd15.prod.outlook.com>
 <MN2PR15MB256034533A31A7C11E3C347985C39@MN2PR15MB2560.namprd15.prod.outlook.com>
 <CAEudQAocYZieAMgCtXa8Oau8=dVJ1_R1r0coLeF1LfiYkBCTNA@mail.gmail.com>
 <20210822154758.GZ10479@telsasoft.com> <30496.1629654632@sss.pgh.pa.us>
 <MN2PR15MB2560C3FF951319B18A3CA83585C39@MN2PR15MB2560.namprd15.prod.outlook.com>
 <MN2PR15MB25601CCA9E337403E1754BDE85C39@MN2PR15MB2560.namprd15.prod.outlook.com>
 <35729.1629660223@sss.pgh.pa.us>
 <MN2PR15MB2560634E97465D56FFB4601D85C39@MN2PR15MB2560.namprd15.prod.outlook.com>
 <MN2PR1!
 5MB2560F5ABDE7BE85C11625AFD85C39@MN2PR15MB2560.namprd15.prod.outlook.com>
 <846170.1630086205@sss.pgh.pa.us>
 <DM6PR15MB2554454557C7612A93F76A9D85C99@DM6PR15MB2554.namprd15.prod.outlook.com>
 <1050917.1630180243@sss.pgh.pa.us>
 <MN2PR15MB2560A083DA8CD3418BEA1DA085CA9@MN2PR15MB2560.namprd15.prod.outlook.com>
 <CAEudQApD2F17Fz7cQNUZbrx7K3P1Y=KFCc4V3UZthPFgp+radQ@mail.gmail.com>
 <1124170.1630244105@sss.pgh.pa.us>
 <CAEudQAo75GRW3jMsJLXcN1ufXj=BTdkeO5cA_3yqHHJkCWqVag@mail.gmail.com>
 <MN2PR15MB25605C2D5D70A6EAF99B5F6085CA9@MN2PR15MB2560.namprd15.prod.outlook.com>
Comments: In-reply-to "ldh@laurent-hasson.com" <ldh@laurent-hasson.com>
	message dated "Sun, 29 Aug 2021 16:03:02 -0000"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1177684.1630253948.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Sun, 29 Aug 2021 12:19:08 -0400
Message-ID: <1177685.1630253948@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/1177685.1630253948%40sss.pgh.pa.us>
Precedence: bulk

"ldh@laurent-hasson.com" <ldh@laurent-hasson.com> writes:
> Is it possible that the client I am using or the way I am creating the t=
est database might affect this scenario? I use DBeaver and use the default=
 settings to create the database:
> - default encoding: UTF8
> - collate: English_United States.1252
> - ctype: English_United States.1252

Yeah, I was thinking of quizzing you about that.  I wonder whether
something is thinking it needs to transcode to WIN1252 encoding and then
back to UTF8, based on the .1252 property of the LC_XXX settings.  That
shouldn't account for any 500X factor either, but we're kind of grasping
at straws here.

Does Windows have any locale choices that imply UTF8 encoding exactly,
and if so, do your results change when using that?  Alternatively,
try creating a database with WIN1252 encoding and those locale settings.

			regards, tom lane